15 May
2010
15 May
'10
4:48 a.m.
It's about time I finally upgrade my studio machine from UbuntuStudio
8.04. I loaded US 10.04 on a test machine, and was able to run qjackctl,
jackd, and ardour briefly, but then got scared off by another thread here
talking about broken FFADO and nasty interactions with PulseAudio. I also
ran into a bug in xorg that affects any motif-based applications
(right-click context menus don't work, and result in a virtual lock-up)
I'm following the 'distribution usage' thread, looking for the current
'best option', as I have a recording gig scheduled for next Thursday, and
I'd like to be able to validate a new install on my test machine, then
perform another install on the studio laptop before then. There aren't
enough hours in the day...
Currently the test system is loaded with Fedora 12 + CCRMA. My first
attempt to start jack returned some error messages, so I edited
/etc/security/limits.conf as requested, added myself to the audio group,
installed the RT+PAE kernel from the CCRMA repository, rebooted, and tried
it again. Now when I try to start jack from qjackctl (with defaults
only), it quickly results in qjackctl aborting, leaving jack zombified and
unkillable.
Any hints on how to get around this, or do I simply blow it away and try
the next distro on the list(www.linux-sound.org/distro.html), which looks
like it might be AVLinux?
I have past experience with Redhat and SuSe, and for the past three years,
almost exclusively Ubuntu variants, so I'm trying to focus on .deb or
.rpm -based distros.
--
Rick Green
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-Benjamin Franklin
"As for our common defense, we reject as false the choice between our
safety and our ideals."
-President Barack Obama 20 Jan 2009
15 May
15 May
4:53 a.m.
On Fri, 2010-05-14 at 22:48 -0400, Rick Green wrote:
<snip>
I'm following the 'distribution usage'
thread, looking for the current
'best option', as I have a recording gig scheduled for next Thursday, and
I'd like to be able to validate a new install on my test machine, then
perform another install on the studio laptop before then. There aren't
enough hours in the day...
<snip>
Not wanting to pour cold water on anything, but if you've got a gig on
Thursday I wouldn't touch anything on your production rig even if the
test machine works fine.
On the rest, I'm not using any rpm/deb based distros anymore, so can't
really help you. Fedora has a good rep (as you can see from the other
thread) so I'd recommend fixing the errors you're getting.
5:33 a.m.
On Fri, May 14, 2010 at 10:48 PM, Rick Green wrote:
It's about time I finally upgrade my studio
machine from UbuntuStudio 8.04.
I loaded US 10.04 on a test machine, and was able to run qjackctl, jackd,
and ardour briefly, but then got scared off by another thread here talking
about broken FFADO and nasty interactions with PulseAudio. I also ran into
a bug in xorg that affects any motif-based applications (right-click context
menus don't work, and result in a virtual lock-up) I'm following the
'distribution usage' thread, looking for the current 'best option', as I
have a recording gig scheduled for next Thursday, and I'd like to be able to
validate a new install on my test machine, then perform another install on
the studio laptop before then. There aren't enough hours in the day...
Currently the test system is loaded with Fedora 12 + CCRMA. My first
attempt to start jack returned some error messages, so I edited
/etc/security/limits.conf as requested, added myself to the audio group,
installed the RT+PAE kernel from the CCRMA repository, rebooted, and tried
it again. Now when I try to start jack from qjackctl (with defaults only),
it quickly results in qjackctl aborting, leaving jack zombified and
unkillable.
Any hints on how to get around this, or do I simply blow it away and try
the next distro on the list(www.linux-sound.org/distro.html), which looks
like it might be AVLinux?
I have past experience with Redhat and SuSe, and for the past three years,
almost exclusively Ubuntu variants, so I'm trying to focus on .deb or .rpm
-based distros.
Hello,
I am in the Audio Production team of Fedora, we work collaboratively
with CCRMA. We need further information to find the problem.
* First, what version of jack and what version of kernel are you
using? Fedora comes with jack1, whereas the CCRMA has jack2 which
would replace jack1 if you choose so. (We are planning to import jack2
to Fedora soon.)
* What recommendations did you follow for setting
/etc/security/limits.conf? We need to make sure you didn't follow an
advise from a random link from the web. CCRMA's jack2 needs different
settings than Fedora's jack1. CCRMA's jack2 package does the
modifications in /etc/security/limits.conf automatically. Fedora's
jack1 does need some manual tweaking, as specified in
/usr/share/doc/jack-audio-connection-kit-0.118.0/README.Fedora
* What error messages do you get?
* You talked about interactions with pulseaudio but what did you end
up doing? Did you uninstall it?
I recommend joining the CCRMA mailing list, as there are many more
people there to help you. e.g. I can't help you much pulseaudio since
I always remove it from my systems, but there are people at CCRMA who
use it.
http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma
Your experience and opinion are important for us since we don't want
the initial set up to be a turndown for new users.
Thanks,
Orcan
6:33 a.m.
On Fri, 14 May 2010, Orcan Ogetbil wrote:
* First, what version of jack and what version of
kernel are you
using? Fedora comes with jack1, whereas the CCRMA has jack2 which
would replace jack1 if you choose so. (We are planning to import jack2
to Fedora soon.)
I'm running the version that came with the fedora 12
install. That
system is out in the garage, and I'm in the house right now, but I think
it reported v0.113 or something like that when it started. I'm running
one of the CCRMA kernels, I think the first one, without the PAE.
* What recommendations did you follow for setting
/etc/security/limits.conf? We need to make sure you didn't follow an
advise from a random link from the web. CCRMA's jack2 needs different
settings than Fedora's jack1. CCRMA's jack2 package does the
modifications in /etc/security/limits.conf automatically. Fedora's
jack1 does need some manual tweaking, as specified in
/usr/share/doc/jack-audio-connection-kit-0.118.0/README.Fedora
Again, this is from memory, but it was the recommendation that jack
itself put into the qjackctl 'messages' window. I think it was something
like this:
@audio - rtprio 100
@audio - nice -10
* What error messages do you get?
Just the
above, along with something about current user not permitted to
run RT options, so I set up the limits as requested, and added myself to
the audio group.
* You talked about interactions with pulseaudio but
what did you end
up doing? Did you uninstall it?
No that was just negative comments I read on the
mailinglist. I haven't
any indication that my problems are due to PA, yet. Does fedora use PA?
That was one of the reasons I tried fedora 12, because I heard that Ubuntu
was too entangled with PA.
I recommend joining the CCRMA mailing list, as there are many more
people there to help you. e.g. I can't help you much pulseaudio since
I always remove it from my systems, but there are people at CCRMA who
use it.
http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma
Your experience and opinion are important for us since we don't want
the initial set up to be a turndown for new users.
I agree! The planetCCRMA
@home web page was easy to follow, up until
the point that it suggested browsing the repository to select packages.
With fedora 13 only days away, why is the ccrma-audio meta-package still
only available for fedora 11?
I also had trouble trying to install jack. qjackctl didn't draw it in,
and yum wouldn't install jack, jackd, or jackdmp. WTF is the package
called??! I finally just launched qjackctl and pressed the 'start'
button, expecting to get a message about 'jack not found' and maybe a
pointer to the proper package. I was quite surprised to see jackd start
up! It must be a part of the default fedora install. But then, I can't
seem to keep it running for more than 30 seconds...
--
Rick Green
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-Benjamin Franklin
"As for our common defense, we reject as false the choice between our
safety and our ideals."
-President Barack Obama 20 Jan 2009
9:01 a.m.
On Sat, May 15, 2010 at 12:33 AM, Rick Green wrote:
Assuming you are using Fedora's jack (see above), please remove the
lines you added from limits.conf. Then make sure that your username is
in the jackuser group, and in the pulse-rt group (even if you don't
use pulse this setting won't hurt).
You can add your user to these groups by manually editing /etc/group
and adding your username next to these groups, or by running the
system-config-users GUI application and adding the groups to your
username.
Then log-out, log back in or reboot. Now you should have a properly
running jack.
This information is also in the
/usr/share/doc/jack-audio-connection-kit-0.118.0/README.Fedora file.
Check that file out to see if there is anything else you are missing.
Unfortunately yes. Fedora comes with pulseaudio by default. In fact
its developer is a Fedora contributor so that poor Fedora users get
exposed to his experiments. However it is easy to remove pulseaudio.
You just need to do
# yum remove alsa-plugins-pulseaudio pulseaudio pulseaudio-module-jack
In fact, you can remove almost all pulseaudio packages from your
system, except pulseaudio-libs and wine-pulseaudio (if you are using
wine).
Don't know about that. You way want to ask Fernando in CCRMA's list.
On Fri, 14 May 2010, Orcan Ogetbil wrote:
Do a
$ rpm -q jack-audio-connection-kit
If this shows you
jack-audio-connection-kit-0.118.0-1.fc12.<arch>
that means you are using Fedora's jack. If it shows you
jack-audio-connection-kit-1.94-1.fc12.ccrma.<arch>
you are using CCRMA's jack.
* First, what version of jack and what version of
kernel are you
using? Fedora comes with jack1, whereas the CCRMA has jack2 which
would replace jack1 if you choose so. (We are planning to import jack2
to Fedora soon.)
I'm running the version that came with the fedora 12 install. That system
is out in the garage, and I'm in the house right now, but I think it
reported v0.113 or something like that when it started. I'm running one of
the CCRMA kernels, I think the first one, without the PAE.
* What recommendations did you follow for setting
/etc/security/limits.conf? We need to make sure you didn't follow an
advise from a random link from the web. CCRMA's jack2 needs different
settings than Fedora's jack1. CCRMA's jack2 package does the
modifications in /etc/security/limits.conf automatically. Fedora's
jack1 does need some manual tweaking, as specified in
/usr/share/doc/jack-audio-connection-kit-0.118.0/README.Fedora
Again, this is from memory, but it was the recommendation that jack itself
put into the qjackctl 'messages' window. I think it was something like
this:
@audio - rtprio 100
@audio - nice -10
* What error
messages do you get?
Just the above, along with something about current user not
permitted to
run RT options, so I set up the limits as requested, and added myself to the
audio group.
* You talked about interactions with pulseaudio
but what did you end
up doing? Did you uninstall it?
No that was just negative comments I read on the mailinglist. I haven't
any indication that my problems are due to PA, yet. Does fedora use PA?
That was one of the reasons I tried fedora 12, because I heard that Ubuntu
was too entangled with PA.
I recommend joining the CCRMA mailing list, as there are many more
people there to help you. e.g. I can't help you much pulseaudio since
I always remove it from my systems, but there are people at CCRMA who
use it.
http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma
Your experience and opinion are important for us since we don't want
the initial set up to be a turndown for new users.
I agree! The planetCCRMA @home web page was easy to follow, up until the
point that it suggested browsing the repository to select packages. With
fedora 13 only days away, why is the ccrma-audio meta-package still only
available for fedora 11? I also had trouble trying to install jack. qjackctl
didn't draw it in, and
yum wouldn't install jack, jackd, or jackdmp. WTF is the package called??!
I finally just launched qjackctl and pressed the 'start' button, expecting
to get a message about 'jack not found' and maybe a pointer to the proper
package. I was quite surprised to see jackd start up! It must be a part of
the default fedora install. But then, I can't seem to keep it running for
more than 30 seconds...
That's weird.
$ rpm -qR qjackctl
...
libjack.so.0()(64bit)
...
This means that the libjack.so should be dragged in by qjackctl. The
jack package is called "jack-audio-connection-kit". I am not sure if
it is in the default Fedora install. But it is easy to get it
installed. Make sure you also have the alsa-plugins-jack package
installed.
# yum install jack-audio-connection-kit alsa-plugins-jack
Let us know how things go.
Orcan
9:31 p.m.
On Sat, 2010-05-15 at 00:33 -0400, Rick Green wrote:
Hmmm, did you actually install planetccrma-core?
On Fri, 14 May 2010, Orcan Ogetbil wrote:
I you want to try Planet CCRMA you should start by following the
recommendations on how to install it here (maybe you already did?):
http://ccrma.stanford.edu/planetccrma/software/
If you start by installing planetccrma-core-* then you should get a
properly configured rt kernel, misc alsa packages that are not installed
by default and optimization software (rtirq). Installing the kernel
alone is not nearly enough.
Then you should upgrade to the jack package that is part of Planet
CCRMA. This will set up universal access for the realtime schedule (and
you don't need touch anything in /etc/security/*).
* First, what version of jack and what version of
kernel are you
using? Fedora comes with jack1, whereas the CCRMA has jack2 which
would replace jack1 if you choose so. (We are planning to import jack2
to Fedora soon.)
I'm running the version that came with the fedora 12
install. That
system is out in the garage, and I'm in the house right now, but I think
it reported v0.113 or something like that when it started. I'm running
one of the CCRMA kernels, I think the first one, without the PAE.
>
> * What recommendations did you follow for setting
> /etc/security/limits.conf? We need to make sure you didn't follow an
> advise from a random link from the web. CCRMA's jack2 needs different
> settings than Fedora's jack1. CCRMA's jack2 package does the
> modifications in /etc/security/limits.conf automatically. Fedora's
> jack1 does need some manual tweaking, as specified in
> /usr/share/doc/jack-audio-connection-kit-0.118.0/README.Fedora Again, this is from memory, but it was the
recommendation that jack
itself put into the qjackctl 'messages' window. I think it was something
like this:
@audio - rtprio 100
@audio - nice -10
If you install the Planet CCRMA version of jack (1.9.x instead 0.x) then
pulseaudio will automagically release the soundcard that jack wants to
use when jack starts (and reaquire it when jack stops).
* What error messages do you get?
Just
the above, along with something about current user not permitted to
run RT options, so I set up the limits as requested, and added myself to
the audio group.
* You talked about interactions with pulseaudio
but what did you end
up doing? Did you uninstall it?
No that was just negative comments I read on
the mailinglist. I haven't
any indication that my problems are due to PA, yet. Does fedora use PA?
That was one of the reasons I tried fedora 12, because I heard that Ubuntu
was too entangled with PA. I recommend
joining the CCRMA mailing list, as there are many more
people there to help you. e.g. I can't help you much pulseaudio since
I always remove it from my systems, but there are people at CCRMA who
use it.
http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma
Your experience and opinion are important for us since we don't want
the initial set up to be a turndown for new users.
I agree! The planetCCRMA
@home web page was easy to follow, up until
the point that it suggested browsing the repository to select packages.
With fedora 13 only days away, why is the ccrma-audio meta-package still
only available for fedora 11?
Just a matter of time available to do it. I wanted to restructure it and
have been awfully busy. Sorry for the inconvenience.
I also had trouble trying to install jack.
qjackctl didn't draw it in,
and yum wouldn't install jack, jackd, or jackdmp. WTF is the package
called??!
jack-audio-connection-kit
(for example, in a terminal you could say "yum list *jack*" and you
would get a meaningful packages)
If you installed the Planet CCRMA repositories it should have been
available as an upgrade anyway.
I finally just launched qjackctl and pressed the
'start'
button, expecting to get a message about 'jack not found' and maybe a
pointer to the proper package. I was quite surprised to see jackd start
up! It must be a part of the default fedora install. But then, I can't
seem to keep it running for more than 30 seconds...
Try updating jack to the Planet CCRMA jack ("yum install
jack-audio-connection-kit").
-- Fernando
16 May
16 May
9:15 p.m.
On Sat, 15 May 2010, Fernando Lopez-Lezcano wrote:
I you want to try Planet CCRMA you should start by
following the
recommendations on how to install it here (maybe you already did?):
http://ccrma.stanford.edu/planetccrma/software/
I was following
http://ccrma.stanford.edu/planetccrma/software/installplaneteleven.html,
which is linked off that page. I got stuck at the point of
enabling the CCRMA repository, when it told me that the meta-package
hadn't been built yet for F12, and I was left to browse the repository for
packages. I was also confused by the presence of two separate
repositories: 'PlanetCCRMA' and 'PlanetCCRMA Core'. ISTR fedora being
called 'fedora core' in the early days, and this led me off into a tangent
trying to learn what the difference is, and which I should be using...
If you start by installing planetccrma-core-* then you
should get a
properly configured rt kernel, misc alsa packages that are not installed
by default and optimization software (rtirq). Installing the kernel
alone is not nearly enough.
Looking back thru my command history, I find I have attempted the
following:
yum upgrade
rpm -Uvh
http://ccrma.stanford.edu/planetccrma/mirror/fedora/linux/planetccrma/12/i3…
yum install planetccrma-apps /* didn't work */
yum install ardour
yum install jack ffado /* jack not found, but ffado was installed */
yum install planetccrma-core
yum install qjackctl
At this point,I launched qjackctl and attempted to start jack. It asked
me to update limits.conf for the audio group, so I did, and added myself
to the audio group. I rebooted, and tried it again. This time, not only
did jack fail, but qjackctl aborted as well. ps tells me that jack is
still there, zombified....
So here is where I stand now:
[root@angel ~]# yum list installed planetccrma* jack* ardour* ffado*
Loaded plugins: presto, refresh-packagekit
Installed Packages
ardour.i686 2.8.7-1.fc12 @updates
ffado.i686 2.0.0-1.fc12.ccrma @planetccrma
jack-audio-connection-kit.i686 0.118.0-1.fc12 @updates
planetccrma-core.i686 2010.01.21-1.fc12.ccrma @planetcore
planetccrma-repo.noarch 1.1-2.fc12.ccrma installed
Then you should upgrade to the jack package that is
part of Planet
CCRMA. This will set up universal access for the realtime schedule (and
you don't need touch anything in /etc/security/*).
OK, I'm running `yum upgrade` which is picking up the newer j-a-c-k as
well as 12 others, including several qt and xorg packages.
Now, trying again. I launch qjackctl. The messsage window pops up and
immediately tells me: 'cannot connect to jack server'. I don't worry too
much, because I haven't yet tried to start jack.
So I push the 'start' button, without first even looking at the defaults
in the 'setup' page. The message window scrolls by a bunch of messages,
and I'm able to see that jackdmp v 1.94 is indeed there. But then it
locks up, and I get an SElinux popup with two errors. The first is from
three days ago, when I was making my first attempts:
Summary:
SELinux is preventing /usr/sbin/abrtd (deleted) "write" access on abrt.
...I don't know how 'abrtd' is related to jack, it may be just
coincidence.
Then the second one, today:
Summary:
SELinux is preventing /usr/bin/jackd from loading
/usr/lib/libffado.so.2.0.0
which requires text relocation.
Detailed Description:
The jackd application attempted to load /usr/lib/libffado.so.2.0.0 which
requires text relocation. This is a potential security problem. Most
libraries
do not need this permission. Libraries are sometimes coded incorrectly and
request this permission. The SELinux Memory Protection Tests
(http://people.redhat.com/drepper/selinux-mem.html) web page explains how
to
remove this requirement. You can configure SELinux temporarily to allow
/usr/lib/libffado.so.2.0.0 to use relocation as a workaround, until the
library
is fixed. Please file a bug report.
Allowing Access:
If you trust /usr/lib/libffado.so.2.0.0 to run correctly, you can change
the
file context to textrel_shlib_t. "chcon -t textrel_shlib_t
'/usr/lib/libffado.so.2.0.0'" You must also change the default file
context
files on the system in order to preserve them even on a full relabel.
"semanage
fcontext -a -t textrel_shlib_t '/usr/lib/libffado.so.2.0.0'"
Fix Command:
chcon -t textrel_shlib_t '/usr/lib/libffado.so.2.0.0'
Additional Information:
Source Context
unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1
023
Target Context system_u:object_r:lib_t:s0
Target Objects /usr/lib/libffado.so.2.0.0 [ file ]
Source jackd
Source Path /usr/bin/jackd
Port <Unknown>
Host angel.aapsc.com
Source RPM Packages jack-audio-connection-kit-1.9.4-1.fc12.ccrma
Target RPM Packages libffado-2.0.0-1.fc12.ccrma
Policy RPM selinux-policy-3.6.32-113.fc12
Selinux Enabled True
Policy Type targeted
Enforcing Mode Enforcing
Plugin Name allow_execmod
Host Name angel.aapsc.com
Platform Linux angel.aapsc.com
2.6.31.12-1.rt20.1.fc12.ccrma.i686.rtPAE #1
SMP
PREEMPT RT Thu Jan 21 22:07:32 EST 2010 i686
athlon
Alert Count 2
First Seen Sun 16 May 2010 02:50:02 PM EDT
Last Seen Sun 16 May 2010 02:50:02 PM EDT
Local ID d2aeb4a1-1065-4d28-87c0-0f573876e08f
Line Numbers
Raw Audit Messages
node=angel.aapsc.com type=AVC msg=audit(1274035802.313:27312): avc:
denied { execmod } for pid=4623 comm="jackd"
path="/usr/lib/libffado.so.2.0.0" dev=dm-0 ino=7903
scontext=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
tcontext=system_u:object_r:lib_t:s0 tclass=file
node=angel.aapsc.com type=SYSCALL msg=audit(1274035802.313:27312):
arch=40000003 syscall=125 success=no exit=-13 a0=42d92000 a1=176000 a2=5
a3=bf8e6a00 items=0 ppid=4618 pid=4623 auid=500 uid=500 gid=500 euid=500
suid=500 fsuid=500 egid=500 sgid=500 fsgid=500 tty=(none) ses=1
comm="jackd" exe="/usr/bin/jackd"
subj=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 key=(null)
...it gives me two commands to use to reconfigure selinux to allow an
exception for libffado, and I copy and paste them into a root console, but
that does not unlock jack or qjackctl. I was able to kill qjackctl, but
jackd is zombified:
[root@angel ~]# ps aux | grep jack
rtg 2156 99.3 0.0 0 0 ? Zsl May14 3186:39 [jackd]
<defunct>
rtg 4623 0.0 0.9 79948 19284 ? DL 14:50 0:00
/usr/bin/jackd -dalsa -dhw:0 -r48000 -p1024 -n2
root 4685 0.0 0.0 4212 712 pts/0 S+ 15:09 0:00 grep jack
...so it looks like my only option at this point is to send off this email
and reboot the system before trying again.
--
Rick Green
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-Benjamin Franklin
"As for our common defense, we reject as false the choice between our
safety and our ideals."
-President Barack Obama 20 Jan 2009
9:59 p.m.
...continuation of my adventures with Fedora12 + CCRMA:
OK, so I rebooted to get rid of the zombified jack.
I again launch qjackctl, and press the start button.
Progress! No SELinux messages, and jack starts up.
I launch Ardour. It presents a window new to me, asking about 'audio
setup'. I leave it at the defaults, and press 'start audio engine'. It
then tells me that jack is already running as another user. Doh!
So I think "Hey, they've improved Ardour, so I no longer need to use
qjackctl to get jack started first. Why won't they connect to an
already-running jack, though??" I close Ardour.
I go back to qjackctl, and press 'stop'. The display changes from
'started' to 'stopping'. I wait. Nothing more happens, and it appears
that after all the trouble getting jack started, now it won't stop!
...another reboot. This is not acceptable. It's looking too much like
another OS I hate...
Now I launch Ardour, and let it start jack for me. I open a little test
session containing only a single short track. I press the 'play' button,
and nothing happens. I try hitting the space bar, and nothing happens. I
click on the timeline, and the playhead moves as expected. I press the
'return to zero' button, and nothing happens.
This was a session recorded with another version of Ardour (on US 10.04),
so I think it might be a compatibility issue. So I stop ardour, and then
re-start it to open a new session and try that. It gives me a message
that it couldn't start jack because it was already running as another
user. This jack won't die, either:
[rtg@angel ~]$ killall jackd
[rtg@angel ~]$ ps aux | grep jack
rtg 2109 75.4 3.7 91232 77064 ? RLsl 15:29 19:28
/usr/bin/jackd -T -ndefault -p 128 -R -P 60 -T -d alsa -n 2 -r 48000 -p
1024 -d hw:0,0
rtg 2206 0.0 0.0 4212 712 pts/1 S+ 15:55 0:00 grep jack
[rtg@angel ~]$ kill 2109
[rtg@angel ~]$ ps aux | grep jack
rtg 2109 75.8 3.7 91232 77064 ? RLsl 15:29 19:55
/usr/bin/jackd -T -ndefault -p 128 -R -P 60 -T -d alsa -n 2 -r 48000 -p
1024 -d hw:0,0
rtg 2208 0.0 0.0 4212 716 pts/1 S+ 15:55 0:00 grep jack
[rtg@angel ~]$ kill -s 9 2109
[rtg@angel ~]$ ps aux | grep jack
rtg 2109 77.4 3.7 91232 77064 ? RLs 15:29 21:54
/usr/bin/jackd -T -ndefault -p 128 -R -P 60 -T -d alsa -n 2 -r 48000 -p
1024 -d hw:0,0
rtg 2210 0.0 0.0 4212 716 pts/1 S+ 15:57 0:00 grep jack
...I'm getting pretty sick of these reboots!
--
Rick Green
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-Benjamin Franklin
"As for our common defense, we reject as false the choice between our
safety and our ideals."
-President Barack Obama 20 Jan 2009
10:27 p.m.
On Sun, May 16, 2010 at 3:59 PM, Rick Green wrote:
...continuation of my adventures with Fedora12 +
CCRMA:
Rick, it really won't help us if you don't tell us what versions of
jack-audio-connection-kit, qjackctl, pulseaudio, kernel, and ardour
you are running.
I know you are frustrated. But let's help each other, shall we?
rpm -q jack-audio-connection-kit qjackctl pulseaudio kernel ardour
uname -r
Orcan
11:58 p.m.
On Sun, 16 May 2010, Orcan Ogetbil wrote:
On Sun, May 16, 2010 at 3:59 PM, Rick Green wrote:
That information was mostly presented in the first post today:
/excerpt/
[root@angel ~]# yum list installed planetccrma* jack* ardour* ffado*
Loaded plugins: presto, refresh-packagekit
Installed Packages
ardour.i686 2.8.7-1.fc12 @updates
ffado.i686 2.0.0-1.fc12.ccrma
@planetccrma
jack-audio-connection-kit.i686 0.118.0-1.fc12 @updates
planetccrma-core.i686 2010.01.21-1.fc12.ccrma
@planetcore
planetccrma-repo.noarch 1.1-2.fc12.ccrma installed
...continuation of my adventures with Fedora12 +
CCRMA:
Rick, it really won't help us if you don't tell us what versions of
jack-audio-connection-kit, qjackctl, pulseaudio, kernel, and ardour
you are running.
I know you are frustrated. But let's help each other, shall we?
rpm -q jack-audio-connection-kit qjackctl pulseaudio kernel ardour
uname -r
Then you should upgrade to the jack package that is
part of Planet
CCRMA. This will set up universal access for the realtime schedule (and
you don't need touch anything in /etc/security/*).
OK, I'm running `yum upgrade` which is picking up the newer j-a-c-k as
well as 12 others, including several qt and xorg packages.
/excerpt/
As for qjackctl, that was installed with a 'yum install qjackctl' from the
normal fedora repository. pulseaudio is also stock fedora, if its there,
as I've done nothingto select it, uninstall it, or modify its
configuration since installing f12.
Unfortunately, I can't run the specific queries you requested right now.
Just after I sent off the last email, my video card seems to have
overheated, and my display went blank. Neither ssh nor telnet seems to be
enabled in the default f12 install, so I'm stuck until I shut it down and
let it cool off, or buy a new video card.
--
Rick Green
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-Benjamin Franklin
"As for our common defense, we reject as false the choice between our
safety and our ideals."
-President Barack Obama 20 Jan 2009
--
Rick Green
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-Benjamin Franklin
"As for our common defense, we reject as false the choice between our
safety and our ideals."
-President Barack Obama 20 Jan 2009
17 May
17 May
2:02 a.m.
On Sun, May 16, 2010 at 2:58 PM, Rick Green <rtg(a)aapsc.com> wrote:
jack-audio-connection-kit.i686 0.118.0-1.fc12
@updates
You should do a "yum update" after adding the CCRMA repository. Then you'll
upgrade to the latest Jack:
jack-audio-connection-kit-1.9.4-1.fc12.ccrma.i686
You also need to config /etc/group adding your group name to 'jackuser' just
like you did for
video, audio, polkituser, pulse, pulse-rt, pulse-access, rtkit, cdrom, tape,
and whatever else you need special access to.
After doing that you probably will need to reboot once, unless you know
enough to disable and restart enough systems to get it to reread
/etc/security/limits.conf which are changed by the CCRMA Jackd. Also, you
may not like the particular limits set, I changed mine to:
( see http://old.nabble.com/Re:-Fwd:-jack2-p28288652.html ).
## Automatically appended by the Planet CCRMA jack-audio-connection-kit
## NPM changed '*' to @jackuser to limit priority escalation to jackd.
@jackuser - rtprio 99
@jackuser - memlock 4194304
@jackuser - nice -10
Also, unless you're a masochist, you should totally disable
selinux ("chkconfig --level 0123456 restorcond off") by adding
"selinux=0"
to /boot/grub/grub.conf e.g.
kernel /vmlinuz-2.6.32.11-99.fc12.x86_64 ro
root=/dev/mapper/vg_gnulem-lv_root LANG=en_US.UTF-8
SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=emacs2 vga=0x307
selinux=0 nomodeset 5
Above, in addition to
http://old.nabble.com/uninstall-pulseaudio-to-increase-audio-app-stability-…
I
also disabled the pulseaudio of video -- kernel mode setting -- and behold
the glory of masses of scrolling text at bootup, stable updates, and no
weird ATI radeon bugs.
Speaking of pulseaudio, http://old.nabble.com/Re:-Fwd:-jack2-p28288652.html is
a potential bad interaction between pulseaudio and jack (through
/etc/security/limits.conf, potential priority escalation issue).
Niels
http://nielsmayer.com
3:27 a.m.
On Sun, 16 May 2010, Niels Mayer wrote:
On Sun, May 16, 2010 at 2:58 PM, Rick Green
<rtg(a)aapsc.com> wrote:
I did that this morning.
jack-audio-connection-kit.i686
0.118.0-1.fc12 @updates
You should do a "yum update" after adding the CCRMA repository. Then
you'll
upgrade to the latest Jack:
jack-audio-connection-kit-1.9.4-1.fc12.ccrma.i686
You also need to config /etc/group adding your group name to 'jackuser' just
like you did for
video, audio, polkituser, pulse, pulse-rt, pulse-access, rtkit, cdrom, tape,
and whatever else you need special access to.
After doing that you probably will need to reboot once, unless you know
enough to disable and restart enough systems to get it to reread
/etc/security/limits.conf which are changed by the CCRMA Jackd. Also, you
may not like the particular limits set, I changed mine to:
( see http://old.nabble.com/Re:-Fwd:-jack2-p28288652.html ).
## Automatically appended by the Planet CCRMA jack-audio-connection-kit
## NPM changed '*' to @jackuser to limit priority escalation to jackd.
@jackuser - rtprio 99
@jackuser - memlock 4194304
@jackuser - nice -10
Also, unless you're a masochist, you should totally disable
selinux ("chkconfig --level 0123456 restorcond off") by adding
"selinux=0"
to /boot/grub/grub.conf e.g.
Thanks for all the suggestions. I'll read the articles at those links,
but for now, I'm trying to figure out how to make this system work with a
vanilla configuration as supplied by fedora + CCRMA. My belief is if
those tweaks are necessary, they'll be implemented in either the fedora or
CCRMA install scripts.
a few more observations since my last post:
'desktop' audio isn't working either. I just realized that I'm getting
no beeps or startup sounds from fedora. The motherboard sound system was
detected and automagically configured by Ubuntu, but F12 seems to have
detected it, but not generated a functional configuration. I wonder if
that is causing the lock-ups of jackd and Ardour?
The fedora12 installation didn't detect the other OS installs on the
system, and it over-wrote the MBR, so right now I haven't figured out how
to boot into either my kubuntu 7.10 or Ubuntustudio 10.04 systems. I've
looked at the grub.conf on the various partitions, and they have radically
different syntax, so it looks like f12 and US10.04 are running different
versions of grub, with different config syntax, so I can't simply
cut'n'paste a few menuentry sections into the f12 grub.conf.
--
Rick Green
"The more I learn, The more I learn, how much more there is to learn"
- Charlie Brown
kernel /vmlinuz-2.6.32.11-99.fc12.x86_64 ro
root=/dev/mapper/vg_gnulem-lv_root LANG=en_US.UTF-8
SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=emacs2 vga=0x307
selinux=0 nomodeset 5
Above, in addition to
http://old.nabble.com/uninstall-pulseaudio-to-increase-audio-app-stability-…
I
also disabled the pulseaudio of video -- kernel mode setting -- and behold
the glory of masses of scrolling text at bootup, stable updates, and no
weird ATI radeon bugs.
Speaking of pulseaudio, http://old.nabble.com/Re:-Fwd:-jack2-p28288652.html is
a potential bad interaction between pulseaudio and jack (through
/etc/security/limits.conf, potential priority escalation issue).
3:32 a.m.
On 05/17/2010 11:27 AM, Rick Green wrote:
On Sun, 16 May 2010, Niels Mayer wrote:
Sorry if this has been done but there is a lot of info to go over here.
You may need to run pulseaudio -k before you start jackd. You can add
that line to the start commands in qjackctl.
Also have you verified that the card can play any audio directly through
alsa or pulse audio?
Have you unmuted and adjusted the output with alsamixer or gnome-mixer
You can run alsamixer on the terminal.
Cheers.
Patrick Shirkey
Boost Hardware Ltd
On Sun, May 16, 2010 at 2:58 PM, Rick Green
<rtg(a)aapsc.com> wrote:
I did that this morning.
jack-audio-connection-kit.i686
0.118.0-1.fc12
@updates
You should do a "yum update" after adding the CCRMA repository. Then
you'll
upgrade to the latest Jack:
jack-audio-connection-kit-1.9.4-1.fc12.ccrma.i686
You also need to config /etc/group adding your group name to
'jackuser' just
like you did for
video, audio, polkituser, pulse, pulse-rt, pulse-access, rtkit,
cdrom, tape,
and whatever else you need special access to.
After doing that you probably will need to reboot once, unless you know
enough to disable and restart enough systems to get it to reread
/etc/security/limits.conf which are changed by the CCRMA Jackd. Also,
you
may not like the particular limits set, I changed mine to:
( see http://old.nabble.com/Re:-Fwd:-jack2-p28288652.html ).
## Automatically appended by the Planet CCRMA jack-audio-connection-kit
## NPM changed '*' to @jackuser to limit priority escalation to jackd.
@jackuser - rtprio 99
@jackuser - memlock 4194304
@jackuser - nice -10
Also, unless you're a masochist, you should totally disable
selinux ("chkconfig --level 0123456 restorcond off") by adding
"selinux=0"
to /boot/grub/grub.conf e.g.
Thanks for all the suggestions. I'll read the articles at those
links, but for now, I'm trying to figure out how to make this system
work with a vanilla configuration as supplied by fedora + CCRMA. My
belief is if those tweaks are necessary, they'll be implemented in
either the fedora or CCRMA install scripts.
a few more observations since my last post:
'desktop' audio isn't working either. I just realized that I'm
getting no beeps or startup sounds from fedora. The motherboard sound
system was detected and automagically configured by Ubuntu, but F12
seems to have detected it, but not generated a functional
configuration. I wonder if that is causing the lock-ups of jackd and
Ardour?
The fedora12 installation didn't detect the other OS installs on the
system, and it over-wrote the MBR, so right now I haven't figured out
how to boot into either my kubuntu 7.10 or Ubuntustudio 10.04
systems. I've looked at the grub.conf on the various partitions, and
they have radically different syntax, so it looks like f12 and US10.04
are running different versions of grub, with different config syntax,
so I can't simply cut'n'paste a few menuentry sections into the f12
grub.conf.
kernel /vmlinuz-2.6.32.11-99.fc12.x86_64 ro
root=/dev/mapper/vg_gnulem-lv_root LANG=en_US.UTF-8
SYSFONT=latarcyrheb-sun16 KEYBOARDTYPE=pc KEYTABLE=emacs2 vga=0x307
selinux=0 nomodeset 5
Above, in addition to
http://old.nabble.com/uninstall-pulseaudio-to-increase-audio-app-stability-…
I
also disabled the pulseaudio of video -- kernel mode setting -- and
behold
the glory of masses of scrolling text at bootup, stable updates, and no
weird ATI radeon bugs.
Speaking of pulseaudio,
http://old.nabble.com/Re:-Fwd:-jack2-p28288652.html is
a potential bad interaction between pulseaudio and jack (through
/etc/security/limits.conf, potential priority escalation issue).
3:59 a.m.
On Mon, 2010-05-17 at 11:32 +1000, Patrick Shirkey wrote:
On 05/17/2010 11:27 AM, Rick Green wrote:
If Rick is starting jackd 1.9.4 that is not necessary. Pulse will
relinquish the card when jackd starts.
On Sun, 16 May 2010, Niels Mayer wrote:
Sorry if this has been done but there is a lot of info to go over here.
You may need to run pulseaudio -k before you start jackd. You can add
that line to the start commands in qjackctl. I
also disabled the pulseaudio of video -- kernel mode setting -- and
behold
the glory of masses of scrolling text at bootup, stable updates, and no
weird ATI radeon bugs.
Speaking of pulseaudio,
http://old.nabble.com/Re:-Fwd:-jack2-p28288652.html is
a potential bad interaction between pulseaudio and jack (through
/etc/security/limits.conf, potential priority escalation issue).
Thanks for all the suggestions. I'll read the articles at those
links, but for now, I'm trying to figure out how to make this system
work with a vanilla configuration as supplied by fedora + CCRMA. My
belief is if those tweaks are necessary, they'll be implemented in
either the fedora or CCRMA install scripts.
a few more observations since my last post:
'desktop' audio isn't working either. I just realized that I'm
getting no beeps or startup sounds from fedora. The motherboard sound
system was detected and automagically configured by Ubuntu, but F12
seems to have detected it, but not generated a functional
configuration. I wonder if that is causing the lock-ups of jackd and
Ardour?
The fedora12 installation didn't detect the other OS installs on the
system, and it over-wrote the MBR, so right now I haven't figured out
how to boot into either my kubuntu 7.10 or Ubuntustudio 10.04
systems. I've looked at the grub.conf on the various partitions, and
they have radically different syntax, so it looks like f12 and US10.04
are running different versions of grub, with different config syntax,
so I can't simply cut'n'paste a few menuentry sections into the f12
grub.conf.
Also have you verified that the card can play any
audio directly through
alsa or pulse audio?
It looks likely there is a problem with the soundcard driver. Too many
things are not working as they should.
-- Fernando
Have you unmuted and adjusted the output with
alsamixer or gnome-mixer
You can run alsamixer on the terminal.
Cheers.
Patrick Shirkey
Boost Hardware Ltd
4:13 a.m.
On Sun, 2010-05-16 at 21:27 -0400, Rick Green wrote:
On Sun, 16 May 2010, Niels Mayer wrote:
Not that many "tweaks". The ability for all users to run jack with
realtime scheduling is "added" when you install the Planet CCRMA jack
package. That thread talks about some security problems that could arise
with the use of realtime scheduling, that is definitely not the source
of your problems.
On Sun, May 16, 2010 at 2:58 PM, Rick Green
<rtg(a)aapsc.com> wrote:
Speaking of pulseaudio, http://old.nabble.com/Re:-Fwd:-jack2-p28288652.html is
a potential bad interaction between pulseaudio and jack (through
/etc/security/limits.conf, potential priority escalation issue).
Thanks for all the suggestions. I'll read the articles at those links,
but for now, I'm trying to figure out how to make this system work with a
vanilla configuration as supplied by fedora + CCRMA. My belief is if
those tweaks are necessary, they'll be implemented in either the fedora or
CCRMA install scripts. a few more observations since my last post:
'desktop' audio isn't working either.
I was expecting that.
I just realized that I'm getting
no beeps or startup sounds from fedora. The motherboard sound system was
detected and automagically configured by Ubuntu, but F12 seems to have
detected it, but not generated a functional configuration. I wonder if
that is causing the lock-ups of jackd and Ardour?
Most probably (as I state in another email).
You have to first go back to testing very basic stuff.
Hmmm.... I don't know what would be best....
For starters tell us which soundcard you have, that could help
("cat /proc/asound/cards").
Do you have a .wav file handy? You could try playing that using aplay.
That is, in a terminal type "aplay NAME_OF_WAV_FILE.wav". Do you get
sound? Any errors? Is the level up? (there should be a small "speaker"
icon in your top panel, use it to bring up the level).
If there is no sound and no errors what is it that happens?
The fedora12 installation didn't detect the other
OS installs on the
system, and it over-wrote the MBR, so right now I haven't figured out how
to boot into either my kubuntu 7.10 or Ubuntustudio 10.04 systems. I've
looked at the grub.conf on the various partitions, and they have radically
different syntax, so it looks like f12 and US10.04 are running different
versions of grub, with different config syntax, so I can't simply
cut'n'paste a few menuentry sections into the f12 grub.conf.
AFAIK fc12 uses the "normal" grub? I'm not sure. _Some_ distro had
switched to grub2 but I don't know which. Argh.......
-- Fernando
5:59 a.m.
On Sun, 16 May 2010, Fernando Lopez-Lezcano wrote:
For starters tell us which soundcard you have, that
could help
("cat /proc/asound/cards").
[rtg@angel ~]$ cat /proc/asound/cards
0 [SI7012 ]: ICH - SiS SI7012
SiS SI7012 with ALC655 at irq 18
Do you have a .wav file handy? You could try playing
that using aplay.
That is, in a terminal type "aplay NAME_OF_WAV_FILE.wav". Do you get
sound? Any errors? Is the level up? (there should be a small "speaker"
icon in your top panel, use it to bring up the level).
Well, it seems to be
working now. I mounted my home partition from the
US10.04 system, and began to wander thru it looking for .wav files. When
I encountered one, as soon as I hovered the mouse over it, I began to hear
the piece coming from my speakers.
I then went to the 'sound' preferences panel, and clicked on the various
alert sonds presented there. Each one played itself just fine. This
particular exercise is the one that 'confirmed' to me that it wasn't
working an hour ago. No changes since then other than a reboot.
AFAIK fc12 uses the "normal" grub? I'm
not sure. _Some_ distro had
switched to grub2 but I don't know which. Argh.......
I got around that by booting from the US10.04 DVD and selecting 'rescue',
then re-writing its MBR to the second HDD. Now I can use the BIOS boot
menu to select which HDD to look at, and I've got a triple-boot system
again.
Moving on -
I launched Ardour, opening the 'test' session I had started earlier. I
imported a stereo .wav file into a new track, and attempted to play it.
Same as before: clicking the 'play' button does nothing. The playhead
doesn't move, clock doesn't count, etc. This time, however, the 'go to
start' and 'go to end' buttons do work.
When I try to close the session, Ardour locks up completely. The
'session' menu doesn't even disappear...
top shows me that ardour is still grabbing some cpu cycles every few
seconds, but jackd doesn't show up at all.
`ps aux' shows me this:
[rtg@angel ~]$ ps aux | grep jack
rtg 2234 0.0 3.7 90208 76936 ? SLsl 23:42 0:00
/usr/bin/jackd -T -ndefault -p 128 -R -P 60 -T -d alsa -n 2 -r 48000 -p
1024 -d hw:0,0
rtg 2252 0.0 0.0 4212 712 pts/1 S+ 23:55 0:00 grep jack
[rtg@angel ~]$ ps aux | grep ardour
rtg 2206 2.9 5.8 298672 120568 ? SLl 23:42 0:22
/usr/lib/ardour2/ardour-2.8.7
rtg 2233 0.0 0.0 0 0 ? Z 23:42 0:00
[ardour-2.8.7] <defunct>
rtg 2254 0.0 0.0 4212 716 pts/1 S+ 23:55 0:00 grep
ardour
--
Rick Green
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-Benjamin Franklin
"As for our common defense, we reject as false the choice between our
safety and our ideals."
-President Barack Obama 20 Jan 2009
7:36 a.m.
On Sun, 2010-05-16 at 23:59 -0400, Rick Green wrote:
Most probably whatever happened to jack (with regards to the sound card)
completely hoses the system (driver/hardware/whatever). This is good in
the sense basic audio seems to be working.
Jack uses the most efficient way to access the soundcard and some
hardware is not good enough.
Well, I would __first__ try testing out jack and making sure it works.
Once it starts and runs solidly, then try other things. Ardour with a
non-working jack will not do much (which is what is happening to you).
Start small. Did you try the simple command line I suggested?:
jackd -R -d alsa -d hw:0
(which could even be "jackd -d alsa -d hw:0", you don't need rt to test)
Does it start? What does it print? (add "-v" for more details). Is there
anything in the output of dmesg after running that that looks like a
kernel error?
What I would try if that does not work (and you may need to reboot if it
really messes up things again) is:
jackd -R -d alsa -d hw:0 -p 1024 -n 3
That would increase the number of periods to 3 (you can also try 4)
which seems to make some cards work (specially hda variants). Depends on
the hardware...
-- Fernando
On Sun, 16 May 2010, Fernando Lopez-Lezcano wrote:
Thanks. I don't think I have worked with this one before.
For starters tell us which soundcard you have,
that could help
("cat /proc/asound/cards").
[rtg@angel ~]$ cat /proc/asound/cards
0 [SI7012 ]: ICH - SiS SI7012
SiS SI7012 with ALC655 at irq 18 Do you have a
.wav file handy? You could try playing that using aplay.
That is, in a terminal type "aplay NAME_OF_WAV_FILE.wav". Do you get
sound? Any errors? Is the level up? (there should be a small "speaker"
icon in your top panel, use it to bring up the level).
Well, it seems to be
working now. I mounted my home partition from the
US10.04 system, and began to wander thru it looking for .wav files. When
I encountered one, as soon as I hovered the mouse over it, I began to hear
the piece coming from my speakers.
I then went to the 'sound' preferences panel, and clicked on the various
alert sonds presented there. Each one played itself just fine. This
particular exercise is the one that 'confirmed' to me that it wasn't
working an hour ago. No changes since then other than a reboot. AFAIK fc12
uses the "normal" grub? I'm not sure. _Some_ distro had
switched to grub2 but I don't know which. Argh.......
I got around that by booting from the US10.04 DVD and selecting
'rescue',
then re-writing its MBR to the second HDD. Now I can use the BIOS boot
menu to select which HDD to look at, and I've got a triple-boot system
again.
Moving on -
I launched Ardour, opening the 'test' session I had started earlier. I imported a stereo .wav file into a new track, and
attempted to play it.
Same as before: clicking the 'play' button does nothing. The playhead
doesn't move, clock doesn't count, etc. This time, however, the 'go to
start' and 'go to end' buttons do work.
When I try to close the session, Ardour locks up completely. The
'session' menu doesn't even disappear...
top shows me that ardour is still grabbing some cpu cycles every few
seconds, but jackd doesn't show up at all.
`ps aux' shows me this:
[rtg@angel ~]$ ps aux | grep jack
rtg 2234 0.0 3.7 90208 76936 ? SLsl 23:42 0:00
/usr/bin/jackd -T -ndefault -p 128 -R -P 60 -T -d alsa -n 2 -r 48000 -p
1024 -d hw:0,0
rtg 2252 0.0 0.0 4212 712 pts/1 S+ 23:55 0:00 grep jack
[rtg@angel ~]$ ps aux | grep ardour
rtg 2206 2.9 5.8 298672 120568 ? SLl 23:42 0:22
/usr/lib/ardour2/ardour-2.8.7
rtg 2233 0.0 0.0 0 0 ? Z 23:42 0:00
[ardour-2.8.7] <defunct>
rtg 2254 0.0 0.0 4212 716 pts/1 S+ 23:55 0:00 grep
ardour
10:47 a.m.
Fernando Lopez-Lezcano wrote:
On Sun, 2010-05-16 at 23:59 -0400, Rick Green wrote:
I have. It won't work properly with JACK. Horrible soundcard.
Best,
Jeremy
On Sun, 16 May 2010, Fernando Lopez-Lezcano
wrote:
Thanks. I don't think I have worked with this one before. For starters tell us which soundcard you have,
that could help
("cat /proc/asound/cards").
[rtg@angel ~]$ cat /proc/asound/cards
0 [SI7012 ]: ICH - SiS SI7012
SiS SI7012 with ALC655 at irq 18
4:25 p.m.
On Sun, 16 May 2010, Fernando Lopez-Lezcano wrote:
On Sun, 2010-05-16 at 23:59 -0400, Rick Green wrote:
After comments by Neils and Jeremy, I went rummaging thru the drawers,
and found an old soundblaster, So I disabled the onboard audio, and
plugged in the soundblaster:
[rtg@angel ~]$ cat /proc/asound/cards
0 [Live ]: EMU10K1 - SB Live! Value [CT4831]
SB Live! Value [CT4831] (rev.7, serial:0x80311102)
at 0xbc00, irq 18
[rtg@angel ~]$ jackd -d alsa -d hw:0
jackdmp 1.9.4
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2009 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
no message buffer overruns
no message buffer overruns
JACK server starting in realtime mode with priority 60
audio_reservation_init
Acquire audio card Audio0
creating alsa driver ... hw:0|hw:0|1024|2|48000|0|0|nomon|swmeter|-|32bit
Using ALSA driver EMU10K1 running on card 0 - SB Live! Value [CT4831]
(rev.7, serial:0x80311102) at 0xbc00, irq 18
configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2
periods
ALSA: final selected sample format for capture: 16bit little-endian
ALSA: use 2 periods for capture
ALSA: final selected sample format for playback: 16bit little-endian
ALSA: use 2 periods for playback
...I then opened another console, and checked dmesg and /var/log/messages.
dmesg had no apparent references to audio, but I found this at the end of
/var/log/messages:
May 17 09:34:36 angel rtkit-daemon[1652]: Sucessfully made thread 1650 of
process 1650 (/usr/bin/pulseaudio) owned by '42' high priority at nice
level -11.
May 17 09:34:36 angel rtkit-daemon[1652]: Sucessfully made thread 1655 of
process 1650 (/usr/bin/pulseaudio) owned by '42' RT at priority 5.
May 17 09:34:36 angel rtkit-daemon[1652]: Sucessfully made thread 1657 of
process 1650 (/usr/bin/pulseaudio) owned by '42' RT at priority 5.
May 17 09:34:47 angel kernel: fuse init (API version 7.12)
May 17 09:34:47 angel rtkit-daemon[1652]: Sucessfully made thread 1780 of
process 1780 (/usr/bin/pulseaudio) owned by '500' high priority at nice
level -11.
May 17 09:34:51 angel rtkit-daemon[1652]: Sucessfully made thread 1834 of
process 1834 (/usr/bin/pulseaudio) owned by '500' high priority at nice
level -11.
May 17 09:34:51 angel pulseaudio[1834]: pid.c: Daemon already running.
May 17 09:38:22 angel ntpd[1296]: synchronized to 192.168.156.1, stratum
11
May 17 09:38:22 angel ntpd[1296]: kernel time sync status change 2001
May 17 09:53:28 angel pulseaudio[1780]: sink-input.c: Failed to create
sink input: sink is suspended.
May 17 09:53:28 angel pulseaudio[1780]: sink-input.c: Failed to create
sink input: sink is suspended.
May 17 09:53:28 angel pulseaudio[1780]: sink-input.c: Failed to create
sink input: sink is suspended.
May 17 09:53:32 angel pulseaudio[1780]: sink-input.c: Failed to create
sink input: sink is suspended.
...while jackd is running, desktop audio seems to be suspended. At least
I get no output when I sample the various sounds in
System/preferences/sounds.
...I stop jackd with ^C, it stops cleanly, and desktop audio is
re-enabled!
...I start Ardour, and select my 'test' session. When I click 'open', it
gives me a message about 'I must select a device first'. I poked around
the various tabs, and under 'device' and 'advanced', I found input and
output options that were blank. It offered me choices of 'standard PCM'
or 'Multichannel'. I selected the 'Standard PCM' for both input and
output, and then Ardour was willing to open the session.
...cross my fingers, and click on 'play'. The playhead moves, I see
signal in the level meters, but no sound. I notice that the output
selector on the master bus is '-', so I click on it and select 'out 1-2'.
A good sign, '1/2' is displayed on the output selector. Press Play
again...
Success! It actually gives me sound.
Save the session, close Ardour, and check with ps. Jackd isn't there!
Check desktop sounds - they're enabled again. So far, so good.
Next steps: Hook up the firewire interface and see if it behaves with
ffado...
--
Rick Green
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-Benjamin Franklin
"As for our common defense, we reject as false the choice between our
safety and our ideals."
-President Barack Obama 20 Jan 2009
On Sun, 16 May 2010, Fernando Lopez-Lezcano
wrote:
Thanks. I don't think I have worked with this one before.
For starters tell us which soundcard you have,
that could help
("cat /proc/asound/cards").
[rtg@angel ~]$ cat /proc/asound/cards
0 [SI7012 ]: ICH - SiS SI7012
SiS SI7012 with ALC655 at irq 18
7:36 a.m.
On Sun, May 16, 2010 at 7:12 PM, Fernando Lopez-Lezcano <
nando(a)ccrma.stanford.edu> wrote:
I'm not so sure about that... It might be a good idea to make sure it's not
the same problem described here:
http://old.nabble.com/Re:-Fwd:-jack2-p28296197.html
I experienced the similar lockup problems with jackd/qjackctl prior to my
change (
http://old.nabble.com/help-w--qjackctl-locks-up-X-GUI-(perhaps-caused-by-db…
).
Note that these lockups DO NOT require a reboot. What's happened is that the
GUI/Xserver ends up getting locked up (via qjackctl) so if you SSH in to
your box and "killall qjackctl" you'll unlock ( Make sure to also do
"killall jackd" afterwards.). Unfortunatelythe X server is so locked-up
that you can't Alt-F2 and login via console and kill it that way.
HOWEVER -- in testing out a new $5.00 soundcard, I also experienced
transient lock-ups again with jackd/qjackctl. The one thing that I could
point to consistently as causing problems: having the wrong settings in
'alsamixer', i.e. when one of these is set to "on" you can neither play
directly through ALSA, and jackd will hang:
(
http://old.nabble.com/Re:-QXGEdit-(was-Re:-Suzuki-QC1-Qchord-Digital-Songca…
)
> Speaking
of pulseaudio,
http://old.nabble.com/Re:-Fwd:-jack2-p28288652.html is
> a potential bad interaction between
pulseaudio and jack (through
> /etc/security/limits.conf, potential priority escalation issue).
...
Not that many "tweaks". The ability for all users to run jack with
realtime scheduling is "added" when you install the Planet CCRMA jack
package. That thread talks about some security problems that could arise
with the use of realtime scheduling, that is definitely not the source
of your problems. ** in alsamixer (F3-playback):
Item: "Multi Track Rate Locking" set to [Off]
Item: "Multi Track Rate Reset" set to [Off]
Likewise, if the card is locked to the wrong sampling rate , jack may not be
able to reset it if the above settings are wrong.... To make things worse,
it seems like some of these settings are "sticky" and may require
loading/unloading the driver module or rebooting for the change to take
effect.
Similar badness may be going on w/ your soundcard, which has been a source
of longstanding problems in jack and alsa ... problems that often can be
remedied via alsamixer magic:
http://www.google.com/search?hl=en&q=SiS+SI7012+jackd&aq=f&aqi=…
-- Niels
http://nielsmayer.com
7:49 a.m.
On Sun, 2010-05-16 at 22:36 -0700, Niels Mayer wrote:
On Sun, May 16, 2010 at 7:12 PM, Fernando
Lopez-Lezcano
<nando(a)ccrma.stanford.edu> wrote:
Looks like a different issue. The computer is not locked AFAICT. It was
only rebooted because jackd is unkillable (maybe it could have beeen
killed by kill -9 but that was not tried - even then the
hardware/software might be left in a bad state needing a reboot).
Only Ardour is hung, most probably because jack itself is hung, most
probably due to a driver vs. hardware problem.
> Speaking of pulseaudio,
http://old.nabble.com/Re:-Fwd:-jack2-p28288652.html is
> a potential bad interaction between
pulseaudio and jack
(through
> /etc/security/limits.conf, potential
priority escalation
issue).
...
Not that many "tweaks". The ability for all users to run jack
with
realtime scheduling is "added" when you install the Planet
CCRMA jack
package. That thread talks about some security problems that
could arise
with the use of realtime scheduling, that is definitely not
the source
of your problems.
I'm not so sure about that... It might be a good idea to make sure
it's not the same problem described
here: http://old.nabble.com/Re:-Fwd:-jack2-p28296197.html
I experienced the similar lockup problems with jackd/qjackctl prior to
my change
(
http://old.nabble.com/help-w--qjackctl-locks-up-X-GUI-(perhaps-caused-by-db…
). Note that these lockups DO NOT require a reboot. What's happened is that the
GUI/Xserver ends up getting locked up (via qjackctl) so if you SSH in to your box and
"killall qjackctl" you'll unlock ( Make sure to also do "killall
jackd" afterwards.). Unfortunatelythe X server is so locked-up that you can't
Alt-F2 and login via console and kill it that way. HOWEVER -- in testing out a new $5.00 soundcard, I
also experienced
transient lock-ups again with jackd/qjackctl. The one thing that I
could point to consistently as causing problems: having the wrong
settings in 'alsamixer', i.e. when one of these is set to "on" you can
neither play directly through ALSA, and jackd will hang:
(
http://old.nabble.com/Re:-QXGEdit-(was-Re:-Suzuki-QC1-Qchord-Digital-Songca…
)
** in alsamixer (F3-playback):
Item: "Multi Track Rate Locking" set to [Off]
Item: "Multi Track Rate Reset" set to [Off]
Likewise, if the card is locked to the wrong sampling rate , jack may
not be able to reset it if the above settings are wrong.... To make
things worse, it seems like some of these settings are "sticky" and
may require loading/unloading the driver module or rebooting for the
change to take effect.
Similar badness may be going on w/ your soundcard, which has been a
source of longstanding problems in jack and alsa ... problems that
often can be remedied via alsamixer
magic: http://www.google.com/search?hl=en&q=SiS+SI7012
+jackd&aq=f&aqi=&aql=&oq=&gs_rfai=
Those reasons seem more likely.
We should wait till we hear what comes out of basic tests of command
line invocations of jackd. So far the only test is running ardour which
does not give any feedback on what might be happening.
-- Fernando
7:54 a.m.
On Sun, 2010-05-16 at 22:49 -0700, Fernando Lopez-Lezcano wrote:
Looks like a different issue. The computer is not
locked AFAICT. It was
only rebooted because jackd is unkillable (maybe it could have beeen
killed by kill -9 but that was not tried
Sorry, "-9" was tried and jack was still unkillable. At that point I bet
the kernel had oopsed or something like that. That would make the whole
audio subsystem unavailable until the machine is rebooted, which matches
the symptoms.
-- Fernando
- even then the
hardware/software might be left in a bad state needing a reboot).
Only Ardour is hung, most probably because jack itself is hung, most
probably due to a driver vs. hardware problem.
HOWEVER -- in testing out a new $5.00 soundcard,
I also experienced
transient lock-ups again with jackd/qjackctl. The one thing that I
could point to consistently as causing problems: having the wrong
settings in 'alsamixer', i.e. when one of these is set to "on" you can
neither play directly through ALSA, and jackd will hang:
(
http://old.nabble.com/Re:-QXGEdit-(was-Re:-Suzuki-QC1-Qchord-Digital-Songca…
)
** in alsamixer (F3-playback):
Item: "Multi Track Rate Locking" set to [Off]
Item: "Multi Track Rate Reset" set to [Off]
Likewise, if the card is locked to the wrong sampling rate , jack may
not be able to reset it if the above settings are wrong.... To make
things worse, it seems like some of these settings are "sticky" and
may require loading/unloading the driver module or rebooting for the
change to take effect.
Similar badness may be going on w/ your soundcard, which has been a
source of longstanding problems in jack and alsa ... problems that
often can be remedied via alsamixer
magic: http://www.google.com/search?hl=en&q=SiS+SI7012
+jackd&aq=f&aqi=&aql=&oq=&gs_rfai=
Those reasons seem more likely.
We should wait till we hear what comes out of basic tests of command
line invocations of jackd. So far the only test is running ardour which
does not give any feedback on what might be happening.
19 May
19 May
11:58 p.m.
OK, so after swapping out my soundcard for an old soundblaster Live!, I
can run jack and Ardour with the alsa driver. But that's not the way to
do real work. My testing was interrupted by real life, and the need to
purchase a 6pin - 6pin firewire cable, so that I could plug my saffire
interface into the desktop.
Finally getting back to it today, and of course, it doesn't 'just work'.
Jack aborts soon after starting, with a 'unable to create port' message.
[rtg@angel ~]$ dmesg | grep 1394
ohci1394 0000:00:0c.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[16]
MMIO=[cffef000-cffef7ff] Max Packet=[2048] IR/IT contexts=[4/8]
ieee1394: Host added: ID:BUS[0-00:1023] GUID[005042b514305c8f]
ieee1394: Node added: ID:BUS[0-01:1023] GUID[00130e0100031242]
ieee1394: raw1394: /dev/raw1394 device initialized
Here's an excerpt from lshw:
*-firewire
description: FireWire (IEEE 1394)
product: TSB12LV26 IEEE-1394 Controller (Link)
vendor: Texas Instruments
physical id: c
bus info: pci@0000:00:0c.0
version: 00
width: 32 bits
clock: 33MHz
capabilities: ohci bus_master cap_list
configuration: driver=ohci1394 latency=64 maxlatency=4
mingnt=3
resources: irq:16 memory:cffef000-cffef7ff
memory:cffe4000-cffe7fff
Here's the contents of the qjackctl messages window:
jackdmp 1.9.4
Copyright 2001-2005 Paul Davis and others.
Copyright 2004-2009 Grame.
jackdmp comes with ABSOLUTELY NO WARRANTY
This is free software, and you are welcome to redistribute it
under certain conditions; see the file COPYING for details
JACK server starting in realtime mode with priority 60
libffado 2.0.0 built Jan 21 2010 16:27:49
firewire ERR: FFADO: Error creating virtual device
Cannot attach audio driver
JackServer::Open() failed with -1
no message buffer overruns
Failed to start server
17:17:04.825 JACK was stopped with exit status=255.
17:17:04.828 Post-shutdown script...
17:17:04.832 killall jackd
jackd: no process killed
17:17:05.342 Post-shutdown script terminated with exit status=256.
17:17:06.197 Could not connect to JACK server as client. - Overall
operation failed. - Unable to connect to server. Please check the messages
window for more info.
Cannot connect to server socket err = No such file or directory
Cannot connect to server socket
jack server is not running or cannot be started
When I saw the ffado message 'cannot attach audio driver', I thought it
might be a faulty firewire card, so I swapped it for another one, also
based on the TI TSB12LV26. I got the same error.
I find it quite annoying that qjackctl then goes into an 18 second retry
loop, popping up the same error box which prevents me from scrolling thru
the messages window and reading the messages until I acknowledge it, then
it gives me only 18 seconds to browse until it annoys me again. If I
wanted it to try again, I would have pushed the 'start' button again!
Grrr.
Hmmm, ffado-diag seems to tell me I have permission problems:
[rtg@angel ~]$ ffado-diag
FFADO diagnostic utility 0.1
============================
(C) 2008 Pieter Palmers
/snip/
IOError: [Errno 13] Permission denied: '/dev/raw1394'
[root@angel ~]# ls -al /dev/raw1394
crw-rw----. 1 root root 171, 0 2010-05-19 16:55 /dev/raw1394
Should I add myself to the 'root' group, or should I change the group
ownership of that device to something else?
Anyway, here's ffado-diag run as root:
[root@angel ~]# ffado-diag
FFADO diagnostic utility 0.1
============================
(C) 2008 Pieter Palmers
=== CHECK ===
Base system...
kernel version............ 2.6.31.12-1.rt20.1.fc12.ccrma.i686.rtPAE
FIXME: implement test for RT kernel
RT patched............... False
old 1394 stack present.... False
old 1394 stack loaded..... False
old 1394 stack active..... True
new 1394 stack present.... False
new 1394 stack loaded..... False
new 1394 stack active..... False
/dev/raw1394 node present. True
/dev/raw1394 permissions.. True
Prerequisites (dynamic at run-time)...
gcc................ sh: gcc: command not found
g++................ sh: g++: command not found
PyQt............... sh: pyuic: command not found
jackd.............. no message buffer overruns
path............. /usr/bin/jackd
flags............ Package jack was not found in the pkg-config search
path.
Perhaps you should add the directory containing `jack.pc'
to the PKG_CONFIG_PATH environment variable
No package 'jack' found
libraw1394......... Package libraw1394 was not found in the pkg-config
search path.
Perhaps you should add the directory containing `libraw1394.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libraw1394' found
flags............ Package libraw1394 was not found in the pkg-config
search path.
Perhaps you should add the directory containing `libraw1394.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libraw1394' found
libavc1394......... Package libavc1394 was not found in the pkg-config
search path.
Perhaps you should add the directory containing `libavc1394.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavc1394' found
flags............ Package libavc1394 was not found in the pkg-config
search path.
Perhaps you should add the directory containing `libavc1394.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libavc1394' found
libiec61883........ Package libiec61883 was not found in the pkg-config
search path.
Perhaps you should add the directory containing `libiec61883.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libiec61883' found
flags............ Package libiec61883 was not found in the pkg-config
search path.
Perhaps you should add the directory containing `libiec61883.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libiec61883' found
libxml++-2.6....... Package libxml++-2.6 was not found in the
pkg-config search path.
Perhaps you should add the directory containing `libxml++-2.6.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libxml++-2.6' found
flags............ Package libxml++-2.6 was not found in the
pkg-config search path.
Perhaps you should add the directory containing `libxml++-2.6.pc'
to the PKG_CONFIG_PATH environment variable
No package 'libxml++-2.6' found
dbus-1............. Package dbus-1 was not found in the pkg-config
search path.
Perhaps you should add the directory containing `dbus-1.pc'
to the PKG_CONFIG_PATH environment variable
No package 'dbus-1' found
flags............ Package dbus-1 was not found in the pkg-config
search path.
Perhaps you should add the directory containing `dbus-1.pc'
to the PKG_CONFIG_PATH environment variable
No package 'dbus-1' found
Prerequisites (static at compile-time)...
gcc................ gcc (GCC) 4.4.2 20091222 (Red Hat 4.4.2-20)
g++................ g++ (GCC) 4.4.2 20091222 (Red Hat 4.4.2-20)
PyQt............... sh: pyuic: command not found
jackd.............. could not open driver .so
'/usr/lib/jack/jack_firewire.so': libffado.so: cannot open shared object
file: No such file or directory
path............. /usr/bin/jackd
flags............ Package jack was not found in the pkg-config search
path.
libraw1394......... 2.0.4
flags............ -lraw1394
libavc1394......... 0.5.3
flags............ -lavc1394 -lrom1394 -lraw1394
libiec61883........ 1.2.0
flags............ -liec61883 -lraw1394
libxml++-2.6....... 2.26.0
flags............ -I/usr/include/libxml++-2.6
-I/usr/lib/libxml++-2.6/include -I/usr/include/libxml2
-I/usr/include/glibmm-2.4 -I/usr/lib/glibmm-2.4/include
-I/usr/include/sigc++-2.0 -I/usr/lib/sigc++-2.0/include
-I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -lxml++-2.6 -lxml2
-lglibmm-2.4 -lgobject-2.0 -lsigc-2.0 -lglib-2.0
dbus-1............. 1.2.16
flags............ -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include
-L/lib -ldbus-1 -lpthread -lrt
Hardware...
Host controllers:
00:0c.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB12LV26 IEEE-1394
Controller (Link) [104c:8020] (prog-if 10 [OHCI])
Subsystem: Texas Instruments Device [104c:8010]
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 64 (750ns min, 1000ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 16
Region 0: Memory at cffef000 (32-bit, non-prefetchable) [size=2K]
Region 1: Memory at cffe4000 (32-bit, non-prefetchable) [size=16K]
Capabilities: [44] Power Management version 1
Flags: PMEClk- DSI- D1- D2+ AuxCurrent=0mA
PME(D0-,D1-,D2+,D3hot+,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: ohci1394
Kernel modules: ohci1394
CPU info:
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 10
model name : mobile AMD Athlon(tm) MP-M 2100+
stepping : 0
cpu MHz : 1600.098
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca
cmov pat pse36 mmx fxsr sse syscall mp mmxext 3dnowext 3dnow up
bogomips : 3200.19
clflush size : 32
power management: ts fid vid
Configuration...
IRQ information
Hardware Interrupts:
--------------------
IRQ 0: PID: None, count: [146], Sched None (priority
None), drivers: ['timer']
IRQ 1: PID: None, count: [4518], Sched None (priority
None), drivers: ['i8042']
IRQ 3: PID: None, count: [2], Sched None (priority
None), drivers: ['']
IRQ 4: PID: None, count: [2], Sched None (priority
None), drivers: ['']
IRQ 7: PID: None, count: [0], Sched None (priority
None), drivers: ['parport0']
IRQ 8: PID: None, count: [0], Sched None (priority
None), drivers: ['rtc0']
IRQ 9: PID: None, count: [0], Sched None (priority
None), drivers: ['acpi']
IRQ 12: PID: None, count: [32988], Sched None (priority
None), drivers: ['i8042']
IRQ 14: PID: None, count: [11193], Sched None (priority
None), drivers: ['pata_sis']
IRQ 15: PID: None, count: [45612], Sched None (priority
None), drivers: ['pata_sis']
IRQ 16: PID: None, count: [3928], Sched None (priority
None), drivers: ['radeon', 'ohci1394']
IRQ 17: PID: None, count: [33981], Sched None (priority
None), drivers: ['sata_sil']
IRQ 18: PID: None, count: [111], Sched None (priority
None), drivers: ['EMU10K1']
IRQ 19: PID: None, count: [8033], Sched None (priority
None), drivers: ['eth0']
IRQ 20: PID: None, count: [0], Sched None (priority
None), drivers: ['ohci_hcd:usb2']
IRQ 21: PID: None, count: [0], Sched None (priority
None), drivers: ['ohci_hcd:usb3']
IRQ 23: PID: None, count: [199414], Sched None (priority
None), drivers: ['ehci_hcd:usb1']
Software Interrupts:
--------------------
=== REPORT ===
FireWire kernel drivers:
[PASS] Kernel drivers statically linked into the kernel.
[PASS] /dev/raw1394 node present and accessible.
...I tried `chgrp audio /dev/raw1394`, because I had earlier added
myself to the 'audio' group at the suggestion of jackd 0.118.
Lo and Behold! I can run ffado-diag as my own user. qjackctl will start
jack. Ardour will open my 'test' session, and play the one track there,
and after about ten minutes of playing around, not a single xrun!
--
Rick Green
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-Benjamin Franklin
"As for our common defense, we reject as false the choice between our
safety and our ideals."
-President Barack Obama 20 Jan 2009
20 May
20 May
12:14 a.m.
On Wed, 19 May 2010 16:58:28 -0500, Rick Green <rtg(a)aapsc.com> wrote:
...I tried `chgrp audio /dev/raw1394`, because I had earlier added
myself to the 'audio' group at the suggestion of jackd 0.118.
This will work until your next reboot.
Create /etc/udev/rules.d/99-firewire.rules with the following contents:
# IEEE1394 (firewire) devices
# Please note that raw1394 gives unrestricted, raw access to every single
# device on the bus and those devices may do anything as root on your
system.
# Yes, I know it also happens to be the only way to rewind your video
camera,
# but it's not going to be group "video", okay?
KERNEL=="raw1394", GROUP="audio"
KERNEL=="dv1394*", GROUP="audio"
KERNEL=="video1394*", GROUP="audio"
--Steve
1:43 a.m.
On Wed, 19 May 2010, S C Rigler wrote:
On Wed, 19 May 2010 16:58:28 -0500, Rick Green
<rtg(a)aapsc.com> wrote:
Yup, I discovered that.
...I tried `chgrp audio /dev/raw1394`, because I had earlier added myself
to the 'audio' group at the suggestion of jackd 0.118.
This will work until your next reboot.
Create /etc/udev/rules.d/99-firewire.rules with the following contents:
# IEEE1394 (firewire) devices
# Please note that raw1394 gives unrestricted, raw access to every single
# device on the bus and those devices may do anything as root on your system.
# Yes, I know it also happens to be the only way to rewind your video camera,
# but it's not going to be group "video", okay?
KERNEL=="raw1394", GROUP="audio"
KERNEL=="dv1394*", GROUP="audio"
KERNEL=="video1394*", GROUP="audio"
Thanks!
... I also just stumbled upon Ardour bug #2832: The track 'mute' buttons
don't work as expected by default. Channel level meter goes to zero, but
signal is still routed to all sends and outputs. It's supposedly fixed in
current svn, but both fedora12 and US10.04 versions have it.
Circumvention is an edit to ~/.ardour2/ardour.rc
--
Rick Green
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-Benjamin Franklin
"As for our common defense, we reject as false the choice between our
safety and our ideals."
-President Barack Obama 20 Jan 2009
1:49 a.m.
On Wed, 2010-05-19 at 19:43 -0400, Rick Green wrote:
On Wed, 19 May 2010, S C Rigler wrote:
Does it work correctly for you? If so, I could add this to the Planet
CCRMA jack package.
-- Fernando
On Wed, 19 May 2010 16:58:28 -0500, Rick Green
<rtg(a)aapsc.com> wrote:
Yup, I discovered that.
...I tried `chgrp audio /dev/raw1394`, because I had earlier added myself
to the 'audio' group at the suggestion of jackd 0.118.
This will work until your next reboot.
Create /etc/udev/rules.d/99-firewire.rules with the following contents:
# IEEE1394 (firewire) devices
# Please note that raw1394 gives unrestricted, raw access to every single
# device on the bus and those devices may do anything as root on your system.
# Yes, I know it also happens to be the only way to rewind your video camera,
# but it's not going to be group "video", okay?
KERNEL=="raw1394", GROUP="audio"
KERNEL=="dv1394*", GROUP="audio"
KERNEL=="video1394*", GROUP="audio"
Thanks!
3:59 a.m.
On Wed, 19 May 2010, Fernando Lopez-Lezcano wrote:
(re: udev update for raw1394 permissions)
Does it work correctly for you? If so, I could add
this to the Planet
CCRMA jack package.
Yes, I installed it just as S C Rigler suggested, and after a reboot, the
raw1394 device was available to the 'audio' group, and I could launch jack
with the firewire driver.
This, however, is dependent on my being a member of the audio group. I
did that manually a few days ago, to get around another issue I was
having. Looking thru /etc/group now, I see a 'jackuser' group. Is that
one you defined, and is it the 'preferred' group to put users into for
pro-audio work? If so, maybe it would be better to assign /dev/raw1394 to
jackuser instead.
In any case, I would suggest adding a section to the 'installing CCRMA on
F11 & 12' describing the need to subscribe the user to *some* priviledged
group in order to access the specialized hardware.
I would also suggest moving the section on the RT kernel up higher, as the
first item after adding the CCRMA repositories, before even thinking about
playing with applications.
--
Rick Green
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-Benjamin Franklin
"As for our common defense, we reject as false the choice between our
safety and our ideals."
-President Barack Obama 20 Jan 2009
4:14 a.m.
On Wed, 2010-05-19 at 21:59 -0400, Rick Green wrote:
On Wed, 19 May 2010, Fernando Lopez-Lezcano wrote:
(re: udev update for raw1394 permissions)
No, jackuser is created and used by the Fedora jack package.
I have always given access to realtime scheduling to all users, so that
you don't need to do anything with group membership (the simplest out of
the box experience). That is, of course, not as secure as having a group
for that purpose (as someone will surely point out), but, well, it is
what I do at CCRMA. Anyone can use jack, anyone can mess up a computer
using it :-)
Does it work correctly for you? If so, I could
add this to the Planet
CCRMA jack package.
Yes, I installed it just as S C Rigler suggested, and after a reboot, the
raw1394 device was available to the 'audio' group, and I could launch jack
with the firewire driver.
This, however, is dependent on my being a member of the audio group. I
did that manually a few days ago, to get around another issue I was
having. Looking thru /etc/group now, I see a 'jackuser' group. Is that
one you defined, and is it the 'preferred' group to put users into for
pro-audio work? If so, maybe it would be better to assign /dev/raw1394 to
jackuser instead. In any case, I would suggest adding a section to the
'installing CCRMA on
F11 & 12' describing the need to subscribe the user to *some* priviledged
group in order to access the specialized hardware.
If you install the Planet CCRMA package for jack there is no need to do
that.
I would also suggest moving the section on the RT
kernel up higher, as the
first item after adding the CCRMA repositories, before even thinking about
playing with applications.
It _was_ higher :-)
Sigh.
It is difficult to know what is best to do. There is no recipe that will
work best for everyone.
In the past there was more chance that the Planet CCRMA kernel would not
work in a machine where the Fedora kernel would - I think that chance is
lower these days as I can roll out rt kernels that have almost the same
patches as the Fedora ones. And for a big chunk of users the current
Fedora kernels are "good enough" (it depends on the kind of work you
do). So I decided to lower the priority of installing and testing the
realtime kernel.
I should make it more clear that it is best to install the Planet CCRMA
jack package...
Or, the permissions could be handled through a different package that is
installed independently of jack.
-- Fernando
4:59 a.m.
On Wed, 19 May 2010, Fernando Lopez-Lezcano wrote:
I have always given access to realtime scheduling to
all users, so that
you don't need to do anything with group membership (the simplest out of
the box experience). That is, of course, not as secure as having a group
for that purpose (as someone will surely point out), but, well, it is
what I do at CCRMA. Anyone can use jack, anyone can mess up a computer
using it :-)
That's probably appropriate in your lab, where all users are
audio
users, but CCRMA@home might find other little fingers curiously poking
about...
Yes, the old 'security vs. convenience' tradeoff. I'm not knowledgable
enough to quantify the risks associated with jack and those associated
with raw1394. Would you want to give both to everybody? How would you go
about it? Fedora creates a group for each user, so there's no 'users'
group. Can a udev rule be written to chmod o+rw /dev/raw1394?
(shudder...) If you decide that even one item should be limited to group
access, then you need to remind the users to add themselves to that group,
and you might as well restrict the other resources to that group as well.
I should make it more clear that it is best to install the Planet CCRMA
jack package...
Yes, just a reminder to 'yum upgrade' after installing
the repositories.
--
Rick Green
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-Benjamin Franklin
"As for our common defense, we reject as false the choice between our
safety and our ideals."
-President Barack Obama 20 Jan 2009
4:39 a.m.
One other thing I've encountered:
I can now run ardour after starting jack with qjackctl, but if I start
Ardour first, and go to the 'audio setup' tab and select 'FFADO', then the
interface box is empty, as well as the 'input interface' and 'output
interface' boxes on the 'advanced' tab. The pulldowns give me no options,
either. I don't see anything like this reported as a bug on the Ardour
tracker. I wonder if it's still an anomaly in my config? I do see the
same mis-behaviour on both my US10.04 and FC12/CCRMA test systems.
Is anybody else seeing this?
--
Rick Green
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-Benjamin Franklin
"As for our common defense, we reject as false the choice between our
safety and our ideals."
-President Barack Obama 20 Jan 2009
2:47 p.m.
On Wed, May 19, 2010 at 10:39 PM, Rick Green <rtg(a)aapsc.com> wrote:
One other thing I've encountered:
I can now run ardour after starting jack with qjackctl, but if I start
Ardour first, and go to the 'audio setup' tab and select 'FFADO', then
the
interface box is empty, as well as the 'input interface' and 'output
interface' boxes on the 'advanced' tab. The pulldowns give me no options,
either. I don't see anything like this reported as a bug on the Ardour
tracker. I wonder if it's still an anomaly in my config? I do see the same
mis-behaviour on both my US10.04 and FC12/CCRMA test systems.
Ardour's audio setup tab has no real support for FFADO at this time. The
audio setup tab was created primarily for OS X users. If you are on Linux, I
strongly, *strongly* recommend that you use qjackctl or some other
equivalent tool to run JACK.
--p
3:38 p.m.
On Thu, 20 May 2010, Paul Davis wrote:
On Wed, May 19, 2010 at 10:39 PM, Rick Green
<rtg(a)aapsc.com> wrote:
Thanks. I've been using qjackctl on my US8.04 system, and I'll continue
with my new system.
I wonder if someday qjackctl, ffado-mixer, and possibly others would be
adapted to a 'plug-in' architecture so that they could be launched as
needed from Ardour. The benefits of integration without having to
duplicate all that code??
--
Rick Green
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-Benjamin Franklin
"As for our common defense, we reject as false the choice between our
safety and our ideals."
-President Barack Obama 20 Jan 2009
One other thing I've encountered:
I can now run ardour after starting jack with qjackctl, but if I start
Ardour first, and go to the 'audio setup' tab and select 'FFADO', then
the
interface box is empty, as well as the 'input interface' and 'output
interface' boxes on the 'advanced' tab. The pulldowns give me no options,
either. I don't see anything like this reported as a bug on the Ardour
tracker. I wonder if it's still an anomaly in my config? I do see the same
mis-behaviour on both my US10.04 and FC12/CCRMA test systems.
Ardour's audio setup tab has no real support for FFADO at this time. The
audio setup tab was created primarily for OS X users. If you are on Linux, I
strongly, *strongly* recommend that you use qjackctl or some other
equivalent tool to run JACK.
6:20 p.m.
On 05/20/2010 06:38 AM, Rick Green wrote:
On Thu, 20 May 2010, Paul Davis wrote:
Each jack enabled application would have to adopt that behavior. I
consider jack to be the baseline sound routing system that should start
after login. Then I can fire up a dozen jack enabled apps and patch
them as I see fit.
-Scott
On Wed, May 19, 2010 at 10:39 PM, Rick Green
<rtg(a)aapsc.com> wrote:
Thanks. I've been using qjackctl on my US8.04 system, and I'll
continue with my new system.
I wonder if someday qjackctl, ffado-mixer, and possibly others would
be adapted to a 'plug-in' architecture so that they could be launched
as needed from Ardour. The benefits of integration without having to
duplicate all that code?? One other thing I've encountered:
I can now run ardour after starting jack with qjackctl, but if I start
Ardour first, and go to the 'audio setup' tab and select 'FFADO',
then the
interface box is empty, as well as the 'input interface' and 'output
interface' boxes on the 'advanced' tab. The pulldowns give me no
options,
either. I don't see anything like this reported as a bug on the Ardour
tracker. I wonder if it's still an anomaly in my config? I do see
the same
mis-behaviour on both my US10.04 and FC12/CCRMA test systems.
Ardour's audio setup tab has no real support for FFADO at this time. The
audio setup tab was created primarily for OS X users. If you are on
Linux, I
strongly, *strongly* recommend that you use qjackctl or some other
equivalent tool to run JACK.
6:48 p.m.
On Thu, May 20, 2010 at 9:20 AM, Scott <lau(a)troutpocket.org> wrote:
Each jack enabled application would have to adopt that behavior. I
consider jack to be the baseline sound routing system that should start
after login. Then I can fire up a dozen jack enabled apps and patch them as
I see fit.
That's one of the things I like about qtractor. I can start it up without
qjackctl if I want -- without selecting any patches or hooking up anything.
In qtractor, all the basic connections and patching are part of the template
I set qtractor to launch with (View->Options->Display->Session).
Furthermore, loading a .qtr file for a song will contain the patchbay
information needed to connect to the appropriate midi ports, synths&
instrument definitions, plugin softsynths, etc. You conveniently click on
the "input" or "output" buttons in the mixer panel,. and it'll
show you the
specific jack connection associated with the selected input or output. No
more rats nest of connections to trace through in qjackctl -- I end up using
it more now as an overview of all my connections and use qtractor to setup
specific connections.
So basically, you can just launch qtractor. load your project/song, and be
good to go. You don't have to load&activate a separate patchbay .xml file in
qjackctl in order to connect up whatever you need connected for a particular
session (and remember to associate the patchbay .xml file with your DAW
session). If you want to launch qjackctl to work with qtractor, they work
well together too, but if you forget to launch jack, qtractor will do it for
you. It's really a nice new level of integration we're getting -- an
incremental improvement over a standalone qjackctl.
-- Niels
http://nielsmayer.com
3:37 p.m.
On Wed, May 19, 2010 at 7:43 PM, Rick Green wrote:
... I also just stumbled upon Ardour bug #2832: The
track 'mute' buttons
don't work as expected by default. Channel level meter goes to zero, but
signal is still routed to all sends and outputs. It's supposedly fixed in
current svn, but both fedora12 and US10.04 versions have it. Circumvention
is an edit to ~/.ardour2/ardour.rc
Thanks for spotting this. I'll backported a fix to our Fedora package.
Please download and test:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2198449
Thanks,
Orcan
4:22 p.m.
On Thu, 20 May 2010, Orcan Ogetbil wrote:
Thanks for spotting this. I'll backported a fix to
our Fedora package.
Please download and test:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2198449
I uninstalled ardour, verified that it also deleted the /etc/ardour2/
directory, manually deleted my ~/.ardour2/ directory, and installed your
new i686 package.
I haven't been able to test it. For some strange reason, jackd is
segfaulting every time I try to start it:
(from dmesg:)
jackd[2722]: segfault at 47169c97 ip 47169c97 sp b14b2210 error 4 in
libgcc_s-4.4.3-20100127.so.1[47d47000+1d000]
(from qjackctl message window:)
JACK server starting in realtime mode with priority 60
libffado 2.0.0 built Jan 21 2010 16:27:49
10:11:52.265 Could not connect to JACK server as client. - Overall
operation failed. - Server communication error. Please check the messages
window for more info.
firewire ERR: Could not prepare streaming device!
Cannot attach audio driver
Cannot connect to server socket err = Connection refused
Cannot connect to server socket
Cannot connect to the server
JackServer::Open() failed with -1
If I start ardour, and use its audio setup dialog to select the alsa
backend, I can open my 'test' session. The existing tracks in that
session still retain their disabled mutes, but when I add a new track to
the session, it is created with all four mute points enabled.
A step forward, and a step backwards...
--
Rick Green
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-Benjamin Franklin
"As for our common defense, we reject as false the choice between our
safety and our ideals."
-President Barack Obama 20 Jan 2009
4:43 p.m.
On Thu, May 20, 2010 at 10:22 AM, Rick Green <rtg(a)aapsc.com> wrote:
If I start ardour, and use its audio setup dialog to select the alsa
backend, I can open my 'test' session. The existing tracks in that session
still retain their disabled mutes, but when I add a new track to the
session, it is created with all four mute points enabled.
this is as expected. in ardour2, existing tracks have their own per-track
mute options, resetting the global defaults doesn't affect existing tracks,
just new ones.
24 May
24 May
9:07 p.m.
On Wed, 2010-05-19 at 17:14 -0500, S C Rigler wrote:
On Wed, 19 May 2010 16:58:28 -0500, Rick Green
<rtg(a)aapsc.com> wrote:
Do you happen to know when device permission management move
from /etc/security/console.perms.d/* to udev? Did it move? Are both
mechanisms working?
-- Fernando
...I tried `chgrp audio /dev/raw1394`, because I had earlier added
myself to the 'audio' group at the suggestion of jackd 0.118.
This will work until your next reboot.
Create /etc/udev/rules.d/99-firewire.rules with the following contents:
# IEEE1394 (firewire) devices
# Please note that raw1394 gives unrestricted, raw access to every single
# device on the bus and those devices may do anything as root on your
system.
# Yes, I know it also happens to be the only way to rewind your video
camera,
# but it's not going to be group "video", okay?
KERNEL=="raw1394", GROUP="audio"
KERNEL=="dv1394*", GROUP="audio"
KERNEL=="video1394*", GROUP="audio"
17 May
17 May
2:19 a.m.
On Sun, 16 May 2010, Orcan Ogetbil wrote:
I know you are frustrated. But let's help each
other, shall we?
rpm -q jack-audio-connection-kit qjackctl pulseaudio kernel ardour
uname -r
OK. I found another Radeon card in an old machine, swapped it into my
test machine, and luckily it came up without having to reconfigure X.
Here's the output of the queries you suggested:
[root@angel ~]# rpm -q jack-audio-connection-kit qjackctl pulseaudio
kernel ardour
jack-audio-connection-kit-1.9.4-1.fc12.ccrma.i686
qjackctl-0.3.6-1.fc12.i686
pulseaudio-0.9.21-5.fc12.i686
kernel-2.6.31.5-127.fc12.i686
kernel-2.6.32.11-99.fc12.i686
ardour-2.8.7-1.fc12.i686
[root@angel ~]# uname -r
2.6.31.12-1.rt20.1.fc12.ccrma.i686.rtPAE
I continued poking at the system, and stumbled upon more problems:
Launch Ardour, open new session, selecting 'automatically connect inputs'.
Add two mono tracks to session. Select track 1. Input at top of editor
mixer strip shows a '-', and pop-up when hovering shows 'disconnected'.
I click on it, and select 'in 1'. Input box still shows '-' and hover
text shows 'disconnected', yet when I click on it again, 'in 1' is checked
in the popup menu.
I enable record on that track, enable record in the transport section, and
click the play button. Nothing happens - the record button continues to
flash as if enabled, but the playhead doesn't move. No indication that
anything is being recorded.
I decide to give up there. I click 'session' then 'close', get the
reminder that I haven't saved, and click 'just close'. Nothing happens,
and Ardour locks up. Several minutes later, I issue a kill from a
terminal window, and Ardour disappears.
In that terminal window, I issue 'ps aux | grep jack', and learn that jack
is still running. I attempt to kill it, it doesn't die, then kill it
again with -s 9, to no avail.
I did check /etc/security/limits.conf, and found this at the end:
## Automatically appended by the Planet CCRMA jack-audio-connection-kit
* - rtprio 99
* - memlock 4194304
* - nice -10
-- Rick Green
"Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety."
-Benjamin Franklin
"As for our common defense, we reject as false the choice between our
safety and our ideals."
-President Barack Obama 20 Jan 2009
3:23 a.m.
On Sun, 2010-05-16 at 15:59 -0400, Rick Green wrote:
...continuation of my adventures with Fedora12 +
CCRMA:
OK, so I rebooted to get rid of the zombified jack.
What sort of sound card do you have? This is starting to look like a
sound card problem, jack should not get zombified. What soundcard do you
have? What parameters did you use to start jack?
("cat /proc/asound/cards" to see which cards you have installed).
I again launch qjackctl, and press the start button.
Progress! No SELinux messages, and jack starts up.
I launch Ardour. It presents a window new to me, asking about 'audio
setup'.
That is wrong. If jack is running you should not see anything from
ardour.
I leave it at the defaults, and press 'start audio
engine'. It
then tells me that jack is already running as another user. Doh!
Yup. Maybe as root? You should never use anything as root, there is no
need. Just start everything from the normal user (not root) that you
login as normally.
So I think "Hey, they've improved Ardour, so
I no longer need to use
qjackctl to get jack started first. Why won't they connect to an
already-running jack, though??" I close Ardour.
I go back to qjackctl, and press 'stop'. The display changes from
'started' to 'stopping'. I wait. Nothing more happens, and it appears
that after all the trouble getting jack started, now it won't stop!
...another reboot. This is not acceptable. It's looking too much like
another OS I hate...
... yup...
Usually you don't need to reboot. I don't know why jack is having
problems.
Now I launch Ardour, and let it start jack for me. I
open a little test
session containing only a single short track. I press the 'play' button,
and nothing happens. I try hitting the space bar, and nothing happens. I
click on the timeline, and the playhead moves as expected. I press the
'return to zero' button, and nothing happens.
This was a session recorded with another version of Ardour (on US 10.04),
so I think it might be a compatibility issue.
Unlikely (there is some basic problem with jack).
So I stop ardour, and then
re-start it to open a new session and try that. It gives me a message
that it couldn't start jack because it was already running as another
user. This jack won't die, either:
[rtg@angel ~]$ killall jackd
[rtg@angel ~]$ ps aux | grep jack
rtg 2109 75.4 3.7 91232 77064 ? RLsl 15:29 19:28
/usr/bin/jackd -T -ndefault -p 128 -R -P 60 -T -d alsa -n 2 -r 48000 -p
1024 -d hw:0,0
rtg 2206 0.0 0.0 4212 712 pts/1 S+ 15:55 0:00 grep jack
[rtg@angel ~]$ kill 2109
[rtg@angel ~]$ ps aux | grep jack
rtg 2109 75.8 3.7 91232 77064 ? RLsl 15:29 19:55
/usr/bin/jackd -T -ndefault -p 128 -R -P 60 -T -d alsa -n 2 -r 48000 -p
1024 -d hw:0,0
rtg 2208 0.0 0.0 4212 716 pts/1 S+ 15:55 0:00 grep jack
[rtg@angel ~]$ kill -s 9 2109
[rtg@angel ~]$ ps aux | grep jack
rtg 2109 77.4 3.7 91232 77064 ? RLs 15:29 21:54
/usr/bin/jackd -T -ndefault -p 128 -R -P 60 -T -d alsa -n 2 -r 48000 -p
1024 -d hw:0,0
rtg 2210 0.0 0.0 4212 716 pts/1 S+ 15:57 0:00 grep jack
...I'm getting pretty sick of these reboots!
I also would be sick of rebooting if I were in your shoes!
You should try the simplest possible way to start jack first, from the
command line of a terminal:
jackd -R -d alsa -d hw:0
That should start it with 1024 frames per period, 2 periods at 44100 Hz
sampling rate. See what happens when you do that. The problems you are
having suggests some issue with the soundcard, specially the hung jack
processes. Always run jackd as a normal user (not root).
You could also look at /var/log/messages or the output of dmesg to see
if there any kernel error messages like "Oops" or "BUG" statements.
-- Fernando
15 May
15 May
1:33 p.m.
On 05/15/2010 01:33 PM, Orcan Ogetbil wrote:
On Fri, May 14, 2010 at 10:48 PM, Rick Green wrote:
Dude!!!! Seriously? That is just so wrong in so many ways. It's one
thing for a user to say this for whatever reason but you are claiming to
represent Fedora who also fund a substantial amount of Pulse Audio's
Development. So much for product loyalty.
It's really no wonder people get confused about PA and JACK when even
people with the most opportunity to make the system work together are
bypassing the inherent integration issues by completely side stepping
the problem.
It's about time I finally upgrade my studio
machine from UbuntuStudio 8.04.
I loaded US 10.04 on a test machine, and was able to run qjackctl, jackd,
and ardour briefly, but then got scared off by another thread here talking
about broken FFADO and nasty interactions with PulseAudio. I also ran into
a bug in xorg that affects any motif-based applications (right-click context
menus don't work, and result in a virtual lock-up) I'm following the
'distribution usage' thread, looking for the current 'best option', as I
have a recording gig scheduled for next Thursday, and I'd like to be able to
validate a new install on my test machine, then perform another install on
the studio laptop before then. There aren't enough hours in the day...
Currently the test system is loaded with Fedora 12 + CCRMA. My first
attempt to start jack returned some error messages, so I edited
/etc/security/limits.conf as requested, added myself to the audio group,
installed the RT+PAE kernel from the CCRMA repository, rebooted, and tried
it again. Now when I try to start jack from qjackctl (with defaults only),
it quickly results in qjackctl aborting, leaving jack zombified and
unkillable.
Any hints on how to get around this, or do I simply blow it away and try
the next distro on the list(www.linux-sound.org/distro.html), which looks
like it might be AVLinux?
I have past experience with Redhat and SuSe, and for the past three years,
almost exclusively Ubuntu variants, so I'm trying to focus on .deb or .rpm
-based distros.
Hello,
I am in the Audio Production team of Fedora, we work collaboratively
with CCRMA. We need further information to find the problem.
* First, what version of jack and what version of kernel are you
using? Fedora comes with jack1, whereas the CCRMA has jack2 which
would replace jack1 if you choose so. (We are planning to import jack2
to Fedora soon.)
* What recommendations did you follow for setting
/etc/security/limits.conf? We need to make sure you didn't follow an
advise from a random link from the web. CCRMA's jack2 needs different
settings than Fedora's jack1. CCRMA's jack2 package does the
modifications in /etc/security/limits.conf automatically. Fedora's
jack1 does need some manual tweaking, as specified in
/usr/share/doc/jack-audio-connection-kit-0.118.0/README.Fedora
* What error messages do you get?
* You talked about interactions with pulseaudio but what did you end
up doing? Did you uninstall it?
I recommend joining the CCRMA mailing list, as there are many more
people there to help you. e.g. I can't help you much pulseaudio since
I always remove it from my systems, but there are people at CCRMA who
use it.
http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma
Your experience and opinion are important for us since we don't want
the initial set up to be a turndown for new users.
Thanks,
Orcan
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user(a)lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-user
1:56 p.m.
On Sat, May 15, 2010 at 7:32 AM, Patrick Shirkey wrote:
On 05/15/2010 01:33 PM, Orcan Ogetbil wrote:
And what makes you think I (we) never tried? Fedora is going to make
its 6th release with pulseaudio next week and pulseaudio is still
fundamentally buggy. I really don't want to talk about the hours I
spent on pulseaudio. Did you ever file a bug to pulseaudio? Or did you
try to reason with its developer? I did. Yes, I was stupid. But when
pulseaudio started crashing my wife's computer, and destroying her
hdd, I figured that it was time to react.
Me and many people in Fedora who are dealing with audio are willing to
drop pulseaudio, at least make it non-default. It is a waste of time
and resources to enforce some mobile device company's buggy toy on
Linux desktop users. Unfortunately for the time being, the steering
committee of Fedora does not contain enough people with audio
knowledge to make such a decision.
I am working at Fedora but that does not mean that I support
everything we do. It is a large community and like in all large
communities, we have disagreements. After all these years of
education, I can't promote stupidity. Sorry.
Orcan
I recommend joining the CCRMA mailing list, as there are many more
people there to help you. e.g. I can't help you much pulseaudio since
I always remove it from my systems,
Dude!!!! Seriously? That is just so wrong in so many ways. It's one thing
for a user to say this for whatever reason but you are claiming to represent
Fedora who also fund a substantial amount of Pulse Audio's Development. So
much for product loyalty.
It's really no wonder people get confused about PA and JACK when even people
with the most opportunity to make the system work together are bypassing the
inherent integration issues by completely side stepping the problem.
11:34 p.m.
On 05/15/2010 09:56 PM, Orcan Ogetbil wrote:
On Sat, May 15, 2010 at 7:32 AM, Patrick Shirkey
wrote:
I appreciate that you have personally had a lot of trouble with Pulse
Audio and that integrating it has caused a lot of pain. I have also
experienced the pain and I have also read innumerable reports from other
users. I have definitely attempted to work with the PA team on providing
feedback and have reported my results to this list in excruciating detail.
What makes me laugh is that apart from your personal quest to rid the
world of Pulse Audio on the desktop you are representing Fedora. In my
communications with Lennart he has been very positive in his support of
Fedora's integration efforts for PA and in the past has been quite
dismissive of the efforts made by people on the Ubuntu team. Now what we
have is the Ubuntu team actively pushing the full integration of PA with
Jack ootb and here is one of the core Fedora crew saying that they would
prefer not to ever have to deal with PA ever again and no one else
should have to either.
It makes me wonder if outside forces are not influencing things to
increase confusion and instability for desktop users. They used to have
the ubuntu team in their pockets and now it appears they have managed to
get a spanner in the works at Fedora. Or are you just a lone wolf
defending the world against injustice and attempting to minimise the
hassles you have experienced caused by the headaches of working with PA?
Of course the same could be said of Lennart's often caustic
communication methods being detrimental to progress and it also appears
that you two have some personal issues to sort out which is not helping
anything.
BTW, I completely and wholeheartedly *disagree* with you that PA is a
toy. It is used on Palm, Nokia, and I just found out about Android to
deliver the audio system. In addition to mobile fast becoming the status
quo, having a fully integrated desktop and mobile experience is a
worthwhile pursuit. Maybe you just need a break from working on audio
desktop integration for a while. If you want to farm that out then
contact me privately as I have some spare time these days I could put
into it especially if the funding is available.
Fully integrating the professional a/v stack on Fedora ootb is something
that could use a little attention. I haven't upgraded to f13 yet but f12
is still having some issues in terms of getting various apps to work
together in a fluid system.
I have lots more to add as I have been working with Fedora since f7
which is almost 5 years now specifically because it had the official
endorsement of Lennart for PA integration so I wanted to find out what
all the fuss was about and was sick of hearing this debate when no one
would provide any specific evidence of PA's shortcomings other than "it
didn't work for me so I uninstalled it".
Patrick Shirkey
Boost Hardware Ltd
On 05/15/2010 01:33 PM, Orcan Ogetbil wrote:
And what makes you think I (we) never tried? Fedora is going to make
its 6th release with pulseaudio next week and pulseaudio is still
fundamentally buggy. I really don't want to talk about the hours I
spent on pulseaudio. Did you ever file a bug to pulseaudio? Or did you
try to reason with its developer? I did. Yes, I was stupid. But when
pulseaudio started crashing my wife's computer, and destroying her
hdd, I figured that it was time to react.
Me and many people in Fedora who are dealing with audio are willing to
drop pulseaudio, at least make it non-default. It is a waste of time
and resources to enforce some mobile device company's buggy toy on
Linux desktop users. Unfortunately for the time being, the steering
committee of Fedora does not contain enough people with audio
knowledge to make such a decision.
I am working at Fedora but that does not mean that I support
everything we do. It is a large community and like in all large
communities, we have disagreements. After all these years of
education, I can't promote stupidity. Sorry.
I recommend joining the CCRMA mailing list, as
there are many more
people there to help you. e.g. I can't help you much pulseaudio since
I always remove it from my systems,
Dude!!!! Seriously? That is just so wrong in so many ways. It's one
thing
for a user to say this for whatever reason but you are claiming to represent
Fedora who also fund a substantial amount of Pulse Audio's Development. So
much for product loyalty.
It's really no wonder people get confused about PA and JACK when even people
with the most opportunity to make the system work together are bypassing the
inherent integration issues by completely side stepping the problem.
5289
days inactive
5298
days old
linux-audio-user@lists.linuxaudio.org
42 comments
10 participants
participants (10)
-
Fernando Lopez-Lezcano -
Jeremy -
Ng Oon-Ee -
Niels Mayer -
Orcan Ogetbil -
Patrick Shirkey -
Paul Davis -
Rick Green -
S C Rigler -
Scott