64studio 3.0 observations

Hello all, Have done a reinstall to 3Beta, and after my troubles with UbuntuStudio Nvidia and x.org i'd just like to ask- Can i use the Nvidia driver install app reliably? Which driver did the trick best? i could really do with the performance enhancing effects of accelerated graphics! So far, this looks to be the best 64Studio yet. I had trepidations regarding this version being Ubuntu based i must say. don't get me wrong, i've enjoyed it for other things than multimedia (installed xubuntu on several machines for computer-illiterate relatives, saving them hours of Windows hell) but i did like the fact that 64 was a straight Debian based system previously ;-) Seems pretty great so far Onwards and upwards! http://www.greenheadman.com Psychedelic Soul and so much more...

It certainly is an interesting journey, I'm the medium between your explorations and keeping a stable release including the excellent software you are testing. If the beta3 kernel is working well I would suggest you pin the kernel packages so as to avoid issues. Upgrading the kernel would also see the need to remove\reinstall the nvidia driver. I'll keep alsa\jack as they are for now, while we venture into the world of jack_mixer. Cheers! Dave

Dave, i certainly hear you on this one. Having a stable alsa/jack is of the highest priority. My tests have proved fruitful, but i'm doing this on an AMD64 dual core 5600+ 64bit box/build, so i'm wondering how well the test versions, i.e. 1.0.19 alsa, and 1.9.3 jack, would work out on different configurations, including 32bit. Even jack 1.9.1 might be a better option, as it doesn't contain the new engine profiling code, which has proved to be a small challenge here so far. (Doesn't like the version of Dbus for some reason.) The orginal 2.6.29-rt kernel Free gave us has been excellent here, and has been a big step up in terms of usage, efficiency, and stability. Hard to beat, i think, and definitely useful for a permanent build. (Which i've had since since i switched from testing it, to using it, in my parchment studios build, for daily use.) So to summarise: Free's 2.6.29-r2-RT-kernel Alsa 1.0.19 Jackmp (jack2) 1.9.3 Ardour 2.8 Rosegarden 1.7.3 Drobilla-lad from source/svn (Including patchage, and Ingen, and using by default the latest LV2 code.) Jconv 0.8.0 Ambdec latest Aeolus 0.8.0 Jackmixer (Nedko's) as just discussed. Lash 0.6.0 Denemo 0.8.3, and Denemo git update. (Using 1 and testing the other.) Mscore 0.9.5 Linuxsampler cvs latest, compiled with machine specific flags. libsndfile 1.0.19 A couple of other libs, including up to date rasqal, raptor, and anything else as required by state of the art source builds. Delta44 soundcard, using the ice1712 alsa module I run jack using the midi raw driver, and a2jmidid (from source) to handle cross handling alsa midi to jackmidi. and the NVIDIA pkg2 driver, installed from root prompt at boot, after initial 64 studio beta 3 install, then reboot. More than enough to music with! :) Alex.

The three major software differences I have to you are default jack & alsa. I was planning to keep these two defaulted for comparison. I'm edging slowly towards compiling jack as a test. The third is I'm on the new testing kernel. Quentin has posted a report upstream regarding the testing kernel and I think this could also be playing a big part here. The testing kernel really needs to be worked\tested. Ardour 2.8 seems ok, Rosegarden is playing up a bit now whereas before it was ok, Ardour 3.0 is back to the original one error message. Cheers Dave.

Dave, good to hear! What's your performance figures like now? Alex. p.s. I've just changed /temp to /shm here, as an experiment with jack2 svn 1.9.3, and it seems to have made a small improvement, so we're both in front.

shmfs /dev/shm shm defaults 0 0 Is working the best here. Cheers! dave

Getting more errors now. I have to go out a message for a short while Alex. Will try more when I return. Back soon:-) Cheers! Dave.

I'm just reading some info i googled, and it seems the set sample callback error was depreciated in jackdmp. Not sure what this will do, but i now have jack 1.9.3 (jack2/jackdmp) installed with alsa 1.0.19, and i'm not getting that error. (To be objective, i didn't get it with jack 1.9.0, 1.9.1, or 1.9.2, either.)

there is another setting in the instructions file for /dev i think. Alex. Found it. shmfs /dev/shm shm defaults 0 0 Add this instead of the /temp line in etc/fstab. (Can't have both for some reason.)

oops, after changing fstab: [ERROR]: JACK: jack_set_sample_rate_callback: deprecated [ERROR]: JACK: JackActivationCount::Signal value = 0 ref = 4 [ERROR]: JACK: JackActivationCount::Signal value = 0 ref = 4 Still xruns. Off to try another setting. Cheers Dave.

Still on the defaulted installed jack & alsa. I've made some changes to fstab, going to reboot to see if it helps. Cheers! Dave. ps irc (dave_sn)

Dave, which version of Jack are you using? Alex. p.s. My irc chat handle is alekz12, for reference.

jack_mixer looks interesting, Well worth checking out... tarball or svn? I get this one error when I open a new project with Ardour 3 [ERROR]: JACK: jack_set_sample_rate_callback: deprecated Plus xruns? None with Ardour 2.8 though, any ideas? Cheers! Dave.

Mac, no idea, but i'm not rushing the team. There's a lot of worthy testing work being done by many, so i'd vote for a final, stable, finely tuned, polished, state of the art, and complete release, rather than a hasty one. 2 roubles worth, Alex.

There's a little app from the mighty Nedko called jack_mixer. I've been trying to install this, but have come up with some challenges. The main challenge is the app fails to recognise phat, and phat-dev, as installed dependencies. I've more to do on this today, but so far, the app will eventually build, but fail to use phat widgets for balance, pan, etc.. If anyone's tried this with the beta 3 build, any clues would be appreciated. Now i'm going to rummage around in the makefile, and see what i can find there. http://home.gna.org/jackmixer/ I've tried to get hold of Nedko, and talk to him about this, but no luck so far. Alex. p.s. i think this little app would be a useful addition to 64studio 3.0, hence my interest.

Hi, Is there an official release date for 3.0? Thanks, Mac

No problem Alex, I've been working my way slowly through the maint-guide for a while now. The Debianization process needs research. That one issue with qt had me puzzled with the qmidiarp package. I can move on with this package now. I can see why "Source installs continue to be all the rage at parchment studios... :)" You've been a "great" help and thanks :-) Cheers! Dave.

Nice :-) make worked fine here also. Now I have to research this: maint-guide 2.2 Get the program, and try it out: Quote: You must find instructions on how to correctly compile and install the program (most probably they'll assume you want to install to /usr/local/bin directory; you won't be doing that, but more on that later in Installation in a subdirectory, Section 3.1). 3.1 Installation in a subdirectory And so the journey continues :-) Cheers Dave. Thanks! QT3 it is.

Hi Alex, I've been trying to create a .deb of qmidiarp. I know it's available in the ubuntu repo's but the challenge is to build it from scratch. When the help files are there I do read them, but there's none with this one. Check this out. It seems like one of the tricky ones to me. I've downloaded the source of the ubuntu version for comparison, but I'm still not sure of the compile? QT 4.5 & Mscore svn seems the next step in your testing, good luck and keep us informed Cheers! Dave.

Hi Alex, Good to see you found the fix (nimbus theme errors). $ sudo apt-get upgrade (here shows) The following packages have been kept back: ffmpeg path specific: ./configure parameters: This is one of the areas of compiling I need to research more. This has to be relevant to the upgrade\removal\cleaning of compiled\installed software. I'm sure I could have made things easier for myself. Good work with the Xjadeo build but as you say keeping the balance between up to date and stable use is vital to 64studio. That's why testers are so important. OpenMovieEditor sounds interesting, I'm not sure if I've seen reference to it on the forum, might have been somewhere else. Here's my compile\builds up to now ("not" in any install order). Alsa & Jack are still defaults. ambdec clalsadrv clthreads clxclient jconv zita-convolver zita-resampler drobilla-lad fantasia jsampler kokkini-zita libgig liblscp linuxsampler mscore qsampler rakarrack checkinstall ardour-2.8 Still researching compiling and using "find" & "locate" to see what's where for next test install. $ sudo find / -name "*linuxsampler" $ locate linuxsampler Keep up the good work & Happy Hacking :-) Cheers! Dave.

I spent the day yesterday trying to get Xjadeo working, and it proved to be quite a challenge. Firstly, the old version from etch didn't work at all, and i decided to take a look at a source version. There's been some work done recently on Xjadeo, and the current svn is quite a bit further along than the debian version. All attempts to use the existing ffmpeg failed when trying to install the source version, so i opted for a shiny new ffmpeg from source as well. There's a note on the xjadeo site about being careful which version of ffmpeg to use, and some don't work with current xjadeo, but i couldn't find any definitive guide to this, so crossed the fingers and went for it anyway. After a lot of reading, and quite a few user errors, i figured out that the dependencies required within ffmpeg, for xjadeo need to be path specific, and i could do this when setting ./configure parameters. Even so, setting the path for the repo version of ffmpeg proved fruitless, and it was only when i carefully installed the source ffmpeg, that xjadeo recognised it at compile time. Finally, it worked. Xjadeo (latest svn) is now installed and working, and all that remains for me to do is get my head in the manual and figure out which command line options to use for best performance. So, with the proviso that this will take some patience, and up to date versions of both ffmpeg and xjadeo, it works on 64studio 3.0 Beta3 64bit. I can't suggest the dev team consider this app for inclusion, because of the delicacy of install required, but smarter minds than mine are at work in the 64studio lab, so maybe they might see the worth of packaging this important little app in the 64studio repo. Interesting to note it works fine with Ardour 2.8, and with a little test movie (glosoli), obeyed transport stop/starts without complaint or error. Once the compilation challenge was overcome, the 'modern' Xjadeo is ticking along nicely, and not doing anything unexpected, so far. More to come.... Alex. p.s. I found an interesting little app in the process of doing this, called OpenMovieEditor. It's basic but sturdy, and there's no jack audio option, but what it does do is give accurate specifications for the chosen movie's format, FPS, etc... I found this useful when experimenting with parameters for Xjadeo from the terminal. I simply opened the movie in OME, took a note of the details, closed OME, and opened Xjadeo, specifying framerate, etc. Seemed to work ok, and didn't take long with a bit of practise.

Ok, just tried building it from source, and that went ok, but opening the app got the same segfault. I reckon there's something else going on here, and jackeq and jamin are ok. EUREKA! It's the theme i'm using, called nimbus. I checked the system log, and there's a shedload of nimbus related errors, and segfaults. When i switched back to clearlooks, jamin and jackEQ opened up just fine. So to those who may be interested, DON'T USE THE NIMBUS THEME... Alex. p.s. I reckon livemix might be more well behaved now too.

Hi Alex, I'm not getting errors with jamin or jackeq here. Cheers Dave.

Alex wrote: Ok, another challenge. I get the same flash of gui and segfault with Jamin, as i do with JackEQ. I'll investigate further, but so far, all attempts to get Jamin going have failed. If someone else could check this, i'd be interested in the results. The error is "invalid cast from Gtkmeter to gtkrange." here's what backtrace i could get. Alex.

Ok, another challenge. I get the same flash of gui and segfault with Jamin, as i do with JackEQ. I'll investigate further, but so far, all attempts to get Jamin going have failed. If someone else could check this, i'd be interested in the results. The error is "invalid cast from Gtkmeter to gtkrange." here's what backtrace i could get. http://paste.ubuntu.com/141665/ Alex.

Hi Alex. I enabled the repository and checked out Nedko's work and it looks great. I didn't install anything more just yet because I want to take stock of the install\upgrades so far. I want to spend more time learning to use the software I've already compiled before adding more. I have two PC's side by side so I've been comparing a clean beta3 to my testing\compile beta3 to see the changes made so far. The system is still running great here. Keep up the good work :-) Cheers! Dave.

I'd like to draw the 64studio team's attention to Nedko's work with Jack, Lash, Ladi tools, etc.. Nedko has done some fine work and continues to do so. I've had the privilege of testing some of this stuff in its early days. But relevant to 64studio 3.0, he has a PPA of apps that are up to date, and possibly worthy of inclusion in 3.0. Here's the address: https://launchpad.net/~nedko Of particular interest is LASH 0.6.0, and it's natural patchbay GUI, lpatchage. I've just added his PPA repo to synaptic, and installed LASH 0.6.0, and lpatchage, and it's all working fine so far, with 64studio 64bit v3.0 beta 3. Alex. Reference to an earlier post, i've been testing Ambdec, and it works without error. (From Fons at Kikkini Zita.)

livemix is an app i use from time to time when quick drafting with a large LS template, but don't need Ardour for. The usual plan is to build a template that matches LSampler port for port, then a simple stereo out to system playback. Unfortunately, i've installed the deb from synaptic, but it continues to segfault at startup. This isn't a new challenge, as i've had the same in UBStudio Hardy, and even Debian lenny 5, and there's been a significant swell of similar experiences with other users reporting the same challenges, in the past. If the 64Studio devs could look at this, it would be appreciated, or at least let us know if it's worth using or not in its current form, with 64Studio 3.0. Even from source, Livemix can be problematic, so i'm not waiting with bated breath for a magic cure. :) On the brighter side, Traverso seems to have installed ok, with none of the failed jack driver messages i used to get, at least so far. I'll keep testing this one, as it's useful for recording quick phrases, and short pieces for projects. Alex. As always, i'm doing this in 64bit. If someone's having a good run with livemix in a 32bit environment, with no problems, then there's maybe a clue here somewhere.

This install has become my beta3 Testing\Testing install now. It's running fine also. I only intended to keep it for a short time while practising compiles and builds, but its too nice to replace just yet. The binary nVidia driver install is new so I need to run a few more tests to see how my audio performance has changed. Cheers! Dave.

Just a quick update. I've been hammering 64studio 3.0 beta3, trying to break it, with large orchestral templates, and densely written midi, driving LSampler, out through Ardour2.8 for audio (tons of tracks, busses, and audio and midi ports), and i've been unable to do so. (And this includes a big jconv IR running as well.) My only limitation at the moment seems to be hardware, and that's fairly hefty for an audio box anyway. All my work is internal, so with that proviso, i'll mention here that LSampler with 45 midi ports (jackmidi), and 45 RG midi ports out to a2jmidid bridging alsa and jackmidi, i think this the most stable and accurate playback i've ever had with a linux rig. I'll probably back off these numbers a little, but as an extreme test with the intent of trying to blow something up, i've not done so, so far. I have no idea if external audio/midi devices will perform the same, (i.e. firewire, usb audio, external midi port devices, etc) but with 2 midi keyboards in, and a maniac's view of intent, beta3 is holding up well. Tomorrow, i'll give ambdec a serious workout, and add Aeolus to the mix, and see what happens. The journey continues...... :) Alex. p.s. I'd be interested in hearing from anyone who's using an app called Livemix in this beta 3 build. It used to be a bit fragile in UBstudio (even installed from source), and i'm wondering if it fares any better in 64 studio 3.0. Highly useful app for lashing lots of LSampler audio into a mixer, and tweaking level, etc.., before it hits Ardour. On top of that, it's LASH capable.

CVS does not compete. It is a way to import the bleeding egde source code of a project to a folders on your PC so you can compile and build yourself. Looking into synaptic you will not see the package installed, because the package was not built... Disclaimer - Not all projects are created equal, and it may be unwise to install bleeding edge code on a system that is used for production on a daily basis, unless you know the app to be stable. Ardour 2.0-ongoing is very stable for example in its bleeding edge form, and I have it running on my system, but I would not yet recommend ardour3.0 because of the aggressive development of that branch at the moment.

Hello everyone, Great thread. Alex, I was just wondering about CVS. You mentioned a "bleeding edge" cvs install of Linuxsampler. How does one use CVS?. I'm new to all of this does CVS "compete" with synaptic. How do you set up CVS so you can get the latest versions of software. Thanks tb

Hi Rob, A little practice in the terminal each day can save a lot of mouse work and time. $ sudo apt-cache search "packagename" $ sudo apt-cache show "packagename" $ sudo apt-cache policy "packagename" $ sudo apt-get build-dep "packagename" $ sudo dpkg -l |grep "packagename" e.g. installed packages $ sudo dpkg -l |grep 64studio $ sudo dpkg -s 64studio $ sudo dpkg -s dpkg $ sudo dpkg -s apt Without the quotes. Before long it becomes second nature. As a bonus your .bash_history becomes a useful tool. Browse here for packagenames to practice your searches: You could also install the packages you miss using synaptic. Cheers! Dave.

Still enjoying the beta. However, some things are missing from the Ubuntu bit. It is really nice in Ubuntu to be able to install .DEB files with a single click. It doesn't seem to be on the beta. I know its a small point but I reckon all those Ubuntu users are going to be flocking to use 64Studio, and some of 'em like me like things the same in some ways. I don't get on very well with DPKG; there always seems to be loads of dependancies you have to install as well. I also miss the add/remove programmes bit as well. I know if you are really clever, you never use that anyway...........but I'm not! Just a couple of thoughts Great job chaps! Rob

Hi Alex, I'd missed zita-resampler, (compiled/installed now). Going to keep Alsa and Jack as defaults for now to follow howto and see how everything behaves. Then move on to your Linuxsampler mark2 midi maps howto: Cheers! Dave.

Ok, i just read up, and here's a quick install set for Jconv: There are three libs required for Fon's apps in general. clalsadrv clthreads clxclients See the read me's for install instructions, but Fon's has made it easy with a more or less simple process of 'cd' to dir, make and sudo make install. The default directories are generally /usr/local, but if you wish to change this, you'll need to do so manually in the Makefile, for each lib. Next is zita-convolver, and zita-resampler. As before, make, and make install, from inside each directory, manually adjusting prefix if required. Jconv is much the same as the libs. (There's a theme here) Operation: 'cd' to the dir in which you have the Wav, and .conf file required. My example is York2.conf, which is a modified version of Fon's excellent yorkminster-amb version. And my IR's are in a folder called, erm, ir. So i would do the following in a terminal: alex@parchmentstudios:$ cd ir alex@parchmentstudios/ir:$ jconv york2.conf This will start Jconv, and use the york2.conf, which 'calls' york2.wav. Ensure matching .conf and wav are in the same directory, for trouble free use. Each .conf will need to be built with your particular directory path, so in my case, it's as follows. Copy a .conf file. you can use one of Fon's examples as a template, i.e. chapel.conf., and save it as a new name. Open it, and browse down to the line "/cd /home/fons/acoustics/impresp". Change this to "/cd /your/ir/and/conf/directory" (Meaning your particular ir/conf dir) Read the instructions in the .conf file for wav setup. When you start Jconv, it will tell you if you have configured the .conf successfully, either by starting, or failing with an error message. It's important to get the syntax right, so don't assume there's something wrong with the app, if it doesn't work first time. Options available for configuring a .conf, can be found in the README.CONFIG file in your jconv source file. Jconv is in my parchment studios build by default, as a powerful addition to the musicmaking armoury. It works, and does so efficiently, and consistently. A last note. If you have your system setup to 44100, and the IR you want to use is 48000, jconv will tell you the sample rates don't match. The app will keep running, but for the sake of an efficient system, in which extra CPU cycles aren't taken up resampling convolution, which can be a CPU hungry process, i respectfully suggest any user interested in using Jconv, make a copy of their ir samples, and change the sameplerate. I now have two folders of IRs, one labelled "IR44", and "IR48". Most of my IRs are 48000, but i have successfully resampled copies to 44100, using Rezound. It's quick and easy, and does a good job, with no noticable artifacts, as a result of resampling away from the original samplerate. And as i've recently discovered, the user can also experiment at this stage with testing the wav itself, and finding out where the early reflections finish, and the tail starts. Take a note of the transition, (ideally measured as "samples") and you can configure your Jconv .conf file to "separate" ER, from tail, and assign separate inputs and outputs, for a finer control over ER use for instruments and groups. I'm currently experimenting with 8 ER, and 8 'tail' inputs and outputs, for orchestral instrument and section use. This is done using the controls in the .conf file, and the README.CONFIG gives you details of the functions you can use. This method is also useful for a WAV in which you wish to 'silence' the first 100ms or so, (muting the initial balloon pop, or starting pistol noise, for instance) and just use the rest. In my current test, i use an 8 mono input/output .conf instance, with 1,3,5,7 as the ER ins/outs, and 2,4,6,8 as the tail ins/outs. In Ardour, my recording app, i have sends (pre) from each instrument track going to Jconv, related to sections, or areas within the orchestra. In general, york2.conf ER1 is 1st violins, ER2 is 2nd violins, and the others cover the rest of the orchestra behind the violins. (I plan to expand this, as a test in finer control, to possibly 16 ins/outs, or more, for a dedicated ER for each instrument/section. More to come) The signals coming back into Ardour from Jconv, go to "ER busses", and i have one for each. This gives me the chance to adjust ER signal in relation to dry signal from the instrument track itself, and further refine the end result. (And in my larger .conf test, i will add ER busses, until i have a complete 'set' for an orchestra, corresponding with the number of ER outs from Jconv.) You can also do this using an instrument buss, and 'inserting' an input. This will give a gain slider with which to 'mix' dry and ER signalis within a single instrument buss. Example: 1st violins track in. In the 'pre' box, at the top of the mixer strip, i add a send, called "1vler". This 'sends' to Jconv, a dry signal, from the track input. So i have "1vler" going out to jconv ER1. I add a buss to ardour, called "1st Violins buss." My 1st Violins track outs, are routed to this buss. And i add an "insert" to this buss, called 1VLer. (Note the caps. We can't use duplicate names in Ardour, for sensible reasons, so the caps is a good tip for identifying routing quickly, in your patchbay.) So i now have a single instrument buss, a dry signal in from the track, and an 'inserted' ER signal, with a gain slider for adjustment. (And the buss then routes to a "pre-master' buss, in which i bring all the elements together, before they hit the master track.) This method cuts down on the number of busses you need, particularly for larger track count work. Jconv ER/Tail config: In this example, generously sent to me by Fons, the syntax for separate ER/tail from a single IR is apparent. (This is an ambisonic instance, as an example.) I include the instructions he gave as well: http://paste.ubuntu.com/135884/ And finally, Fons has built in the ability to use /impulse/copy, which means you can use a single instance of an IR, and 'copy' it out as several ins and outs, using the same wav instance. I've tested this, and it's very efficient, reducing CPU cycle use, as instead of loading several instances of the the same IR, to cover multiple ins and outs, the .conf reads just one. (And the same is true if you had more than one IR in the same .conf. Simply /impulse/copy the one you want to copy as new ins/outs, and voila. A more CPU friendly multi-convolution instance.) Alex.

Hi, Nice read on jamin, need to spend more time researching mastering. Here's my compile\builds after following this thread (not in any install order). Alsa & Jack are defaults. ambdec-0.2.4 clalsadrv clthreads-2.4.0 clxclient-3.6.1 jconv-0.8.0 zita-convolver-1.0.0 drobilla-lad Fantasia-0.8a.jar JSampler-0.8a kokkini-zita libgig liblscp linuxsampler mscore-0.9.4 qsampler rakarrack-0.3.0 I'm also very impressed with the beta3 I thought it would have been reinstalled again quite some time back but it's still fine and Alsa, Jack builds would be interesting before reinstalling. I've left them as defaulted for now for comparison. DMX6fire here (ice1712 module) without .asoundrc though I've experimented in the past. Same feedback here it's always just worked but I'll be upgrading with the next computer build. The forum uses Markdown syntax format. This is handy. aGNULa DeMuDi, 64studio. When you find a winner stick with it. Never had any major problems here with either. I have ventured into ubuntustudio JAD, Musix & ccrma fedora, all very nice. Free's work has been on my computer since my first installs of GNU\Linux (DeMuDi 0.9) & (SuSE 8.2). Cheers! Dave.

Dave, good point, and i stress here, i'm testing the limits to a decent stability, then backing off a little, to ensure trouble free writing, every day. When i did the standard install, without my 'tweaks', everything worked fine, as i wrote previously. With my tweaks, what i'm describing is, i guess, a more extreme build, pushing a few boundaries. I continue to be impressed with 64studio beta 3, it's now the base system on the audio box, and i'm enjoying the process of trouble free writing, without having to get the digital spanners out. You'll no doubt remember my initial sortie into linux, and the weeks and months i spent learning, tweaking, and refining, liberally garnished with user errors, and a thousand questions. (I'm still amused by some of the daft mistakes i made.) My soundcard is an M-audio Delta 44, using the ice1712 module. It's proved to be extremely reliable across several flavours of distro, and i think the chaps at Alsa have done a great job on the driver/module. It just works, day after day, and a good sound for orchestral work as a bonus. My .asoundrc is really simple, but highly effective. I don't use anything else on the audio box, just the tools of trade, and i was pleased and delighted to see 64studio bereft of Pulseaudio. Saves me pulling it all out, and i think the build is better for it. As follows: pcm.jackplug { type plug slave { pcm "jack" } } pcm.jack { type jack playback_ports { 0 alsa_pcm:playback_1 1 alsa_pcm:playback_2 } capture_ports { 0 alsa_pcm:capture_1 1 alsa_pcm:capture_2 } } Sorry about the formatting, but i don't know how to fix that, so here's the link: http://www.alsa-project.org/main/index.php/Asoundrc (Down the page to jack plugin.) Nothing remotely related to rocket science in there, and it works without a problem. Everything Alsa goes through Jack, and i have jack2 configured to start when the 'puter boots up. Easy. I'm also of the mind, in a moment of reflection earlier today, that i've hit the right distro at the right time. The journey i've taken so far, seems to have led me to this point, and it takes me about a day now to set up a decent and complete build, and deal with any basic challenges. 64Studio is excellent, and does what it says on the tin. Alex. p.s. The journey continues......

Jamin is a mastering suite, and in order to be a live tool is quite CPU hungry, even while it is apparently doing nothing. What is it in fact doing, is dong nothing very industriously. This way, if you should change any of the settings, the change will be smooth, with no jumps in CPU usage.

I use Jamin a lot. It is the last step in the production chain, preceded by:

• Tracking - the act of recording the individual tracks making up your song. This is the most work of the process, takes the most time, and requires a critical ear by the producer and the audio engineer doing the tracking to ensure the quality of the material
• Mixing - This step is usually done by the same engineer that did the tracking, as having done the tracking gives some preinformation on the quality of the takes which can be useful. This is the formation of the structure of the song from the recorded tracks, and can involve a bit of creative editing to get the most out of the raw tracks. This has a dynamic result, and should not be compressed, with a average loudness of 18dB to 14dB max. while the loudest peak in the song should not hit the rail, saved in a 24bit format.

Mastering is the last step, normally done by someone else. It is the art of hearing a mixed song, and bringing out the essence of what the mixer has intended without changing the feel of the song. Mastering also prepares different tracks for inclusion on an album so that the listener does not have to change the volume after every song.

Hi, Good to see more confirmation of the Timidity bug. Jamin is 30%ish usage on idle here also. Default Alsa & Jack here are fine with default Ardour and builds following Quentins how to on both 2.1 lenny and 3.0 beta3 versions. You are certainly testing them to the max there and I'm thinking the same as you regarding your occasional glitches. My system is fine and I'm pleased with its performance. Considering the benchmark% you are putting on your system it seems great. What sound card do you use? and how are you setting .asoundrc? Cheers! Dave.

I've had two segfaults with Ardour today (no clear error definition), using a big orchestral template, but i think Paul is right. There's something in the Ubuntu build that isn't quite right. I've installed a test from source (svn 2.0-ongoing) and that's been fine. I stress here again, I'm using Alsa 1.0.19, and Jackdmp (Jack2) source. I have built Ardour from source for all my ubuntu/debian builds, eventually, and that's been my most stable result. This has been the biggest hammering i've given ardour so far, and i've got plenty done with the standard 64studio version in this last week or so, during testing, so i tend to think here, it's just the combination of a big LS template, lots of porting, and over 85 tracks, and 40 busses in Ardour, that may be giving the occasional glitch. (And certainly far less than when i used commercial apps, with win or mac, under the same pressure.) Alex.

kaimerra, i don't use either of those apps. Since jackdmp came out, i've built it from source. And it's the same with this version. Ardour works fine here, with fairly minimal CPU, but the few times i've opened Jamin, it's been a bit hungrier, on par with other reports i've read. Alex. p.s. Just installed Ambdec (from Fons), and it built without a hassle.

I removed timidity and did a few music trials. I did some improv with hyrdrogen, zynaddsubfx, with a vocal mic and recorded them into ardour smoothly. I then opened some larger ardour projects and had smooth playback and mastered with jamin and no xruns to speak of. Though, I do find the cpu usage of jamin and ardour at standby troubling. Each of them use about 30% cpu at standstill on my machine, and they use mabye 35% each during playback. What is eating CPU in standby? There are a few screen shots below of this happening if anyone can point out why. They are the last three screenshots on this page. http://picasaweb.google.com/boilingbergstrom/Linux#

I'm curious alex, do you install and run daswatchdog or irqbalence at all? I usually install them and I'm not sure how much they help or hurt. I am going to remove timidity and see if I get a performance boost. Also, I am confused. You mentioned you built/installed Jack2(jackdmp). I was under the impression that 3.0 beta came with jackdmp. When I look at my packages in synaptic, jackd is installed but jackdmp is not. But when I issue jackd -v I get 'jackdmp 0.71'.

Dave, thanks for testing. I'll have a look first and check my GTK stuff is up to date. I don't use it that often, but it's still useful for drafting etc. I wonder if Jack2 (Jackmp) 1.9.1 is part of this too. (JackEQ maybe expecting the old Jack framework..) Alex.

Hi Alex, qjackctl 0.3.4-1~hardy1 JackEQ 0.4.1-1ubuntu2 I'm still using the default installs here and I get no errors. Would you like me to compile\build and see if I hit the segfault or would you like me to check anything else first. Cheers! Dave.