You are not logged in.
FWIW there is a bit of discussion going on at http://groups.google.com/group/proaudio-devel about options to improve the proaudio source and binary package situation kicked off by Holger with this message http://groups.google.com/group/proaudio … cad215274#
Last edited by markc (2008-10-08 03:32:30)
Offline
Yes, I also tried from svn and I get this:
[a@Astudio zyn]$ ./waf install
Checking LV2_PATH : not set
Cannot locate LV2 plugins directory
The install file says:
Installation will try to deduce where to install from your LV2_PATH
unless you specified --lv2-dir during configure stage
But I don't know the correct syntax. Slocate doesn't give me a location but lv2 is installed from AUR.
Hopefully,
Arthur
Offline
See what pacman -Ql lv2 says. It should be obvious where the plugins directory is then either export LV2_PATH=/some/path or add the --lv2-dir=/some/path to the configure line in the PKGBUILD. However, the second option may refer to the whole lv2 installation dir so maybe the first option is best.
Offline
--lv2-dir=/some/path worked!
Thanks so much,
Arthur
Offline
amazing the proaudio for AL lives. I gave up hope but I was stilll trying to update my svn packages....
Offline
Funkmuscle wrote:
this one dude, kernel26rt-2.6.26.3_rt7
I thought it was ok, but it has been freezing but the stock kernel has not. So would anyone be able to email me a .config file for 2.6.26.3_rt (ooh, maybe Funkmuscle?) I don't really know the answers to half of the questions so it's likely that the problem is operator error in the config of the kernel.
Also, would anyone be opposed to my starting a new thread in "kernel & hardware issues" titled "proaudio rt kernel"? This thread is getting very big and difficult to deal with and anyone trying to do audio on Arch will need an RT Kernel to begin with which should be handled in the proaudio wiki. After trying every audio distro on this planet and some not on this planet it is my opinion that Archlinux is where it's at. I have noticed on some mailing lists, that some people are trying to promote Arch Audio. I'm trying to learn so that I can contribute to maintaining PKGBUILDS, but I think that we need to get more organized, meaning that it should be easier for someone to come into Arch and do real audio work OOTB. There are lots of smart people on Ubuntu Studio, 64Studio, JAD and others, that would be happy to contribute if they knew how cool Arch was.
Thanks to you all for your hard work,
Arthur
Offline
@Frabato: your suggestion of another dedicated kernel thread might help get some new eyeballs involved, I say go for it. As for kernel config options, I know some kernel packages, that I added, tried to complete the build automatically without asking any questions because I, and probably most people, would be guessing as to what are or are not the right options to use. We need some concensus or guidelines as to the right config options to use. In fact the main reason I stopped was because of the daunting task of working out the right config options in a way that does not require hours of effort every time a new kernel update comes out... let alone the problems involved getting a new RT patch to compile on top of that. Then there is the issue of getting a current matching ALSA and Jack as a foundation to compile the rest of the packages against. I think we only need 2 such kernel + alsa + jack suites, one older but know-to-work stable version and the latest kernel + rt patch with alsa + jack from trunk repos for testing.
Please, anyone, try and spare a few minutes to add any thoughts to the wiki at http://code.google.com/p/proaudio/w/list. Thanks to Holger for pushing it along.
Offline
exactly like markc said. How long did the latest rt9 kernel take to compile? This has been 24 hours already. I never had a kernel take so long to compile. Thank God I got more that one kernel going in case this baby dies.
Offline
Okay,
Thanks for the suggestions. Later today I'll start a new forum thread under "kernel & hardware issues" titled "proaudio rt kernel + alsa + jack STABLE". The idea of stable and testing is a good one, let's start with stable and not worry yet about bleeding edge. I think that CCRMA is using a 2.6.24 something kernel, I don't think that anyone (64Studio, Musix, Ubuntu Studio etc.) is using anything newer than 2.6.25 but if people here have a working 2.6.26 then that's fine too.
Okay, it's done and it lives here:
http://bbs.archlinux.org/viewtopic.php?id=56688
markc wrote:
Please, anyone, try and spare a few minutes to add any thoughts to the wiki at http://code.google.com/p/proaudio/w/list.
I get "URL not found"
I will rebuild kernel26rt-2.6.26.3_rt7 today and see if I have better luck, again, if anyone has a .config file for this kernel please email it to me and I'll start with it.
Thanks to all,
Arthur
Offline
lol, the link has a dot at the end...
here is a working link: http://code.google.com/p/proaudio/w/list
regarding kernel configs, there's also an initiative by linuxaudio.org-people described here:
http://apps.linuxaudio.org/wiki/kernel/start
with a special mailing list here:
http://lists.linuxaudio.org/listinfo/linux-audio-tuning
but it is relatively new, and not very active as far as i can tell.
holger
Last edited by hb (2008-10-10 14:50:40)
Offline
What I would like to see as far as kernel configs go is an *actual wiki* dedicated to nothing but kernel config options...so when a kernel dev makes an addition deletion or change *someone* (even you or me!) can document the option! The devs are busy coding and there is to my knowledge *nobody* tracking kernel option changes in documentation. But I suppose that's a pipe dream. Anyway I'll end that rant here
@Frabato
I'll meet you on the irc channel if you like and do my best to walk you through the config process.
@all
You guys kick ass! I love the idea of a stable and testing suite. I'm in to contribute whatever I can do...first things first the wiki I think
Offline
Hi All,
So btartsa, I don't know what it takes to start a wiki but I did start this thread:
http://bbs.archlinux.org/viewtopic.php?id=56688
which so far has yielded almost, nearly one response. Maybe it will see some action this weekend.
kernel.org has been down all day so I've been unable to test anything but hopefully it will be up again later tonight or tomorrow.
I think I have a reasonable uderstanding of the kernel options but I still don't know what kernels people are having luck with on Arch.
Funkmuscle, is your kernel26rt-2.6.26.3_rt7 still behaving well? If it is, I'll try to build it again when kernel.org is up again. Also, if it is woking well, could you please email me the .config file that can be found in your /usr/src/yourrtkernel folder?
As this thread has no particular subject I'll continue with this:
Here are a couple of projects that I think are worth looking at:
nice gui's and clean code (as far as a non-dev person can tell)
Thanks to all, I'm really looking forward to what I know Arch ProAudio can be.
Arthur
Offline
dude, I upgraded to the latest rt9 and now jack is freezing. Qjackctl crashes too. I will try a bit longer and if that keeps happening, I will switch back. In that case, which ever version I'm using, I will email you the .config
Offline
Thanks Man!
Offline
This pkgbuild is driving me insane. What the HELL am I missing?
# Contributor: btartsa <btartsa@gmail.com>
pkgname=non-git
pkgver=20081011
pkgrel=1
pkgdesc="Non DAW is a powerful, reliable and fast modular Digital Audio Workstation"
url="http://non-daw.tuxfamily.org/"
license=('GPL')
arch=('i686' 'x86_64')
depends=('fltk' 'jackmp-svn' 'libsndfile' 'lash')
makedepends=('git')
conflicts=()
install=()
source=()
md5sums=()
_gitroot="git://git.tuxfamily.org/gitroot/non/daw.git"
_gitname="daw"
build() {
cd "$srcdir"
msg "Connecting to GIT server...."
if [ -d $_gitname ] ; then
cd $_gitname && git-pull origin
msg "The local files are updated."
else
git clone $_gitroot
fi
msg "GIT checkout done or server timeout"
msg "Starting make..."
rm -r "$srcdir/$_gitname-build"
cp -r "$srcdir/$_gitname" "$srcdir/$_gitname-build"
cd "$srcdir/$_gitname-build"
#
# BUILD HERE
#
./configure --prefix=/usr
make || return 1
make DESTDIR="$pkgdir/usr" install
}
Offline
I just installed it the regular way. It's kinda strange to get use to but it's kinda cool.
I had issue with the build too so I gave up.
Offline
Hey Arthur, dunno if you remember but it's thanksgiving here in Canada so after stuffing myself this weekend, I'll look at the kernel .config file.
Offline
Thanks Funkmuscle but take your time, the kernel.org server has been down for two days and it's still down.
Happy Thanksgiving!
Offline
Hey guys
It looks like we finally have some black-and-white for a TODO so right now I'm concentrating on the kernel. Cross-posting from here: http://groups.google.com/group/proaudio … 802007dce6 (there should've been a prefix in the subject like "[kernel26rt]" but I don't know why Google took it out)
So for the rest of the apps we'll get to them soon, eg. rosegarden + dssi et al.
btartsa: Bad makefile; author didn't code in any variable for destdir. Have to install the files manually. It's just the executable and the icons (they should go to /usr/share/pixmaps). Check out the install rule in the Makefile for a list of what else it does as an install.
-/-/-/-/-/-/-/-/-/-/-/-/-
NOTE: This is for the stock package (when we have a stable and a
current, applies to both); configuration for EVERYONE.
* Do we want the (supposedly) new Real Time Clock system? (No RTC
option for ALSA; I'm not sure how things will work in this case)
* Do we want latency measuring infrastructure? (Frame pointers will be
compiled; becomes a debugger's kernel)
* Do we want Virtualization?
* Do we want all of the Networking options?
* Do we want to ADD/REMOVE anything else from the KERNEL?
* Do we want to ADD/REMOVE anything from the PKGBUILD? (We may not
need to do everything the normal Arch kernel PKGBUILD does, eg. need
remote control support?)
* Do we want to consider patches (Arch or otherwise, eg. Gentoo RT,
JAD, 64Studio, UbuntuStudio) at all?
* Do we want to consider patches for only the current release and
leave the stable clean? (Breaks transition from current to stable,
meaning we now treat them as totally different kernel packages, which
brings us to the next question)
* Do we want to maintain a progressive set of stable and current
kernel packages?
---- Decide upon a trusted and working package initially, label
it as stable. Then, label the latest as the current. After a new
kernel is released, shift the current to stable and continue that way.
---- Decide upon a trusted and working package every time we
THINK we need an update to the stable.
---- Follow upstream schedule, eg. right now there is a
2.6.24 and a 2.6.26 so we can make them stable and current
respectively.
Currently this is what I'm doing:
General setup > +Group CPU Scheduler, +Group scheduling for SCHED_RR/FIFO
Enable the block layer > Default I/O Scheduler > Deadline
Processor type and features > -Paravirtualized guest support, > Timer
frequency > 1000HZ
Power Management options > -APM
Device Drivers > -Real Time Clock, > Character devices > +(m)Enhanced
Real Time Clock Support, +(m)Generic /dev/rtc emulation, +Extended RTC
operation, +HPET
Device Drivers > Sound > Advanced Linux Sound Architecture >
+(M)Sequencer dummy client, +(m)RTC Timer support
According to http://forums.debian.net/viewtopic.php? … =c2949f15e...
Paravirtulization conflicts with Nvidia + RT (need confirmation on
whether I'm taking out the correct option).
This is the supposedly deprecated Real Time Clock system, where we opt
OUT of the many RTC device drivers and use a generic system. If we do
opt IN, the ALSA RTC option cannot be provided. As such, I need some
details on how RTC would relate to ALSA in that case.
-/-/-/-/-/-/-/-/-/-/-/-/-
And yes, happy thanksgiving!
I need real, proper pen and paper for this.
Offline
Hi schivmeister,
It is advised to completely turn off APM support for best results:
Power management options (ACPI, APM) --->
< > APM (Advanced Power Management) BIOS support --->
In case we roll a kernel for deployment we need to turn off most debug/tracing features, as they add significant overhead:
[*] Show timing information on printks
and
[*] Magic SysRq key
should be the only options set in:
Kernel hacking --->
That information is from here:
http://code.goto10.org/projects/puredyn … timization
* Do we want Virtualization?
* Do we want all of the Networking options?
Because I'm not that knowledgeable on these topics, I would think that keeping it as simple as possible would be a good idea.
Most Arch users would be able to config the kernel themselves and turn on any options that would be necessary for their specific needs.
* Do we want to maintain a progressive set of stable and current
kernel packages?---- Decide upon a trusted and working package initially, label
it as stable. Then, label the latest as the current. After a new
kernel is released, shift the current to stable and continue that way.---- Decide upon a trusted and working package every time we
THINK we need an update to the stable.
As I mentioned in an earlier post, most of these distros (64studio, jad, ubuntu studio, ccrma, musix etc.) are using 2.6.24 or 2.6.25 kernels
I think that the first consideration should be to just make sure that it works. Stable should really be stable and current or testing should be 90% stable. Anyone wanting more bleeding edge on Arch probably knows how to build their own kernel.
Enable the block layer > Default I/O Scheduler > Deadline
I've seen "anticipatory" selected here but it's just what I read somewhere so I can't say for sure.
Thanks for taking this on, I wish that I could be of more help technically but I'll be happy to spend lots of time testing whatever you come up with.
Arthur
Offline
hey guys, thank you for the happy thanksgiving. stuffed now...anyway, I just updated to kernel26rt 2.6.26.5_rt9-2.
Jack doesn't work with this kernel??
Jack fails to start now.
00:00:31.465 JACK was started with PID=3141.
jackd 0.109.2
Copyright 2001-2005 Paul Davis and others.
jackd 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 compiled with POSIX SHM support.
cannot use real-time scheduling (FIFO at priority 10) [for thread -1210063168, from thread -1210063168] (1: Operation not permitted)
cannot create engine
00:00:31.562 JACK was stopped successfully.
00:00:31.563 Post-shutdown script...
00:00:31.564 killall jackd
00:00:31.633 ALSA connection change.
jackd: no process killed
00:00:32.004 Post-shutdown script terminated with exit status=256.
00:00:33.663 Could not connect to JACK server as client. - Overall operation failed. - Unable to connect to server. Please check the messages window for more info.
it looks like real-time scheduling. I removed the RT selection in Qjackctl and it works. Don't I need that? I've always used it like that.
Offline
Hi Funkmuscle,
Yes, as far as I know, you do want that. Did you remember to modify /etc/security/limits.conf?
Arthur
Offline
yeah, all that's done. In fact, Ive been trying both PAM and set_rlimits. With RT no selected in qjackctl, the xruns are out of control with no audio apps running. I turn qjackctl on, start jack and watch the xruns go out of control. Then, as I mentioned earlier, jackd doesn't shut down. Even killall doesn't kill it. I justed reinstalled an earlier rt kernel.... will try that now.
This in confusing because many sites suggest to have rt selected.
I should of left things alone. The old saying, if it ain't broke, don't fix it... now it's a mess. Jack will not shut off and I can't fix it or even get the older kernels to work.
Harv
Last edited by funkmuscle (2008-10-13 05:47:37)
Offline
My two cents:
Forget set_rlimits.
I have quit using qjackctl in favor of a small script to start jackd on the command line. Same thing...might help.
Try
sudo kill -9 'pidof jackd'
to kill jackd.
Please post up your /etc/pam.d/su
Offline
/etc/pam.d/su
#%PAM-1.0
auth sufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the "wheel" group.
#auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to require a user to be in the "wheel" group.
#auth required pam_wheel.so use_uid
auth required pam_unix.so
account required pam_unix.so
session required pam_unix.so
What is the script for running jackd?
Offline