64studio 3.0 observations

I'm going through some of the other apps i use from time to time, and hit a snag with JackEQ. I get a persistent segfault when trying to open it, with some sort of GTK error. Before i get further into this, can someone do a quick test, and see if they have the same problem. If not, i'll delve further, and try to figure out what's happening. This was consistent with both the repo version, and the source version. (which i D/L and tried for comparison.) Alex.

Hi Alex, Sure is trial and error on my part, I've mainly used what Free provides with distros. I've been following his work since aGNUla DeMuDi. Great journey. I'm just really venturing into the compile\install world. I want to learn more so I can contribute to Debian Multimedia and help with package maintaining. realtime parchment studios build? Cheers! Dave.

Dave, there's nothing scientific about my 'process' of build, lol. However, i do seem to have a stable result more often than not with the following, based on experience and 4 million user errors. (Still counting) Install kernel/distro (In this case it was a straight install.) Get any graphic issues sorted out. (Please note here, my 64studio 'graphics' install was free of pain, woohoo.) Update Alsa. I've got a bit smarter with this, after several attempts over more than one distro. (Source build) ***NOTE*** I respectfully suggest the 64studio team consider alsa 1.0.19 for a standard install, for the 2.6.29 multimedia kernel. It just plain works, doesn't glitch, or do any of the little sulks that seemed to accompany earlier versions. Even my little G4 /linux ppc Xubuntu build now uses 1.0.19, and the difference in performance and stability is tangible. At least test it for yourself, and see if i'm drawing the right conclusions, or just got very lucky. We get winning combinations sometimes, that just 'click' into place. This one did for me. /end empassioned plea on behalf of new users that may not be as brave/foolish as i am .......... Only once the above is done, do i move on. (Good foundation builds a sturdy palace) Jack. Install Jack, and do all the tweaking and refining. If it doesn't work, i do it again, until it does. Rinse and repeat. Install up to date libs. Libsndfile, libsamplerate, etc.. in other words, all the audio related libs required. QT. I'm looking forward to the day we have up to date builds of this by default, because QT can be a pain in the rear. But it's essential for some apps, and being up to date now, means less pain upgrading later. (RG likes this approach) Only once the above is done, do i move on. (But if i were to update KDE, if i chose to use it, it's this point i'd do that too. I did this with Suse when i tried it, and it paid dividends. Foundation, palace, blah, blah, blah...) Source build of Linuxsampler. This is the meat and potatoes of my setup, so i install this with the right flags, etc. (I include Fantasia in this.) Normally i would source build RG, Ardour, and Jconv here. I've done Jconv for this 64bit 64studio beta 3 build, but RG and Ardour are good to go in the standard install. (I'd dearly like to see Ardour 2.8.1 in the final release, so i hope the 64studio devs will consider this, when Paul finally releases it.) Another lib update, for any extras, like raptor for drobilla-lad, etc.. Install the rest, drobilla-lad, denemo, mscore (sigh), from source, or from straight install, if the version is recent enough. There's been many many errors, and testing done to yield this completely subjective approach, but it works, and testing and checking each stage, as the build profile grows has been worth it. I will say here, that 64studio beta 3 built 'out of the box' for me. (more or less) It only required a couple of tweaks, to have it running nicely. It was after this, that i began adding my requirements, based on my own workflow profile. More to come. :) Alex. p.s. I'm one step ahead of you. Last night i built 64studio with my extra bits, into a realtime parchment studios build. So we're live, and in pursuit of global domination for real!

Hi Alex, Compiling\installing linuxsampler cvs as I type this, then there's only alsa left to do. I probably should have built alsa first? but I have a good idea of the whole process now so I'll make a better job when I start over. Great news about RTC kernel issue. Thanks again for all your guidance ;-) Cheers! Dave.

Dave, I installed alsa 1.0.19 from source, taken from the Alsa website. I didn't do anything to it, just a standard install. Alex.

Hi Alex, The amount of information available regarding these configurations is rare to say the least, you are one of a very few who are looking at this problem. Even finding kernel & alsa 1.0.19 permutations is rare, without adding Mscore, Muse into the equation. I do find references to 2.6.28 and this version of alsa, even then Mscore is missing. You are on new ground here. Going back over the thread is this the only issue remaining: I wonder if Mscore, and Muse use absolute paths, and this is why any variant of rtc (rtc0, rtc1, rtc2) is not sufficient? In the morning I'd like to upgrade alsa to see the results here. Do you have any advice for this? What method did you use? Great work, Checking out this now: Cheers! Dave.

After taking out the rtc-max-user-freq line from /etc/sysctl.conf, i have a clean boot with no errors, except for 2.6.29-multimedia- source not being installed. (Any news on this?) 64studio starts up ok, with no errors, or kernel failure messages. (Which i've never had with this 2.6.29 kernel during runtime. Nice work, Free. :) ) A quick tip for those who may have a challenge getting devices automounted on startup in 64studio 64bit. Install a little app called mountpy. go to sessions/startup programs, and create a new entry with the following command: sudo mountpy Now, when you boot up, devices are mounted automagically. I used to have this challenge in more than one ubuntu/debian build, and mountpy fixed it. This also works on my debian 5 32bit RT build. More to come.... Alex.

The answer is: Yes. the hpet timer can be set for max-user-freq, the same as rtc. Line in /etc/sysctl.conf as follows: dev.hpet.max-user-freq=3072 (My usual setting, and it seems to work ok.) NOTE** dev.rtc.max-user-freq=3072 does NOT work, and records as a failure in bootup, with alsa 1.0.19 version installed. This makes sense to me, as in /proc, rtc is not listed, but hpet is. So i reckon hpet is emulating rtc successfully, but apps like mscore, built to use one timing source only (rtc) can't use hpet, and don't work without a manual symlink in this instance, for the obvious reason rtc in /dev is actually rtc0. I wonder if Mscore, and Muse use absolute paths, and this is why any variant of rtc (rtc0, rtc1, rtc2) is not sufficient. I've just done the hpet freq (3072), and will report back with any challenges, from hammering the system. (The usual method of screwing the latency right down, then gradually backing off, until i hit the 'sweet spot'). I confess i'm enjoying the challenge. :) Alex. p.s. I'm not a geek, honest.

Hi Alex, That's the best response I could have hoped for because you are stating facts where I'm having to go off feelings and google searches (which aren't conclusive). When you say running like a dream then I believe it's running like a dream. If we only have 2 problems Mscore, and Muse, then the hill is not so steep, and if you have a solid foundation with 2.6.29 then that's a great test\result for future development. We just need to research and find fixes if they exist for Mscore, and Muse. It will be a pleasure to travel with you on the journey. Edit: You are testing the base & kernel to fine limits, and it sounds good to me ;-) Cheers! Dave.

You're a mischievous rascal, Dave. I don't get enough sleep as it is, and now you introduce me to PDK!! I'll just have a 'quick' look. :) Personally, i don't think there's a problem with Alsa 1.0.19, and the 2.6.29 64studio kernel. The only apps that seem challenged by this are Mscore, and Muse, and as we've remarked, they're strict in their RTC requirements, to the point of digital petulance. Apart from those two, everything else runs like a dream here, and the foundation of kernel, sound device, and jack server is really stable, at low latency. (I'm running 128/44100/3 without a problem.) So i have confidence in the foundation, and have tended to look further 'up' if there's a challenge of some sort. So far, that perspective has been entirely fruitful. We have different results when setting all this up, but my experience is an extremely good one, so far, and certainly better than other builds i've done. Alex.

Hi Alex, Alex wrote: But i would be interested to know if the rtc0 i see in /dev is actually rtc, or a default hpet emulation. - - - - - Yes I'm thinking along these lines also, but you are light years ahead of my knowledge in these respects. Also not having ALSA 1.0.19 installed limits my testing capabilities, but I'm thinking the 2.6.29 kernel and ALSA 1.0.19 are not playing nicely together and are contributing to the hpet\rtc issues. I am also very impressed with the beta3 and this is why I bumped this thread: PDK. I'm only on the first steps with PDK but I'm able to pull 64studio as it is created. Also the builds I have done include a minimal install cd with Emacs Supercollider. However starting with a minimal install blank canvas sees endless options with someone like yourself who could compile\build to your hearts content. The learning curve is not easy, Daniel & Free released an article in the linuxformat 113 magazine, it was titled "Build your own Distro_PDK the hard way". As it says, not easy but well worth the effort. The options could be e.g. Minimal install, 2.6.29 kernel & blank canvas. Brilliant. ;) I'll research Werner's apps and also the work the Denemo team are doing. Keep in touch I love reading your posts. Cheers! Dave

Hi Alex, I don't have an answer, but as always your post has kept me busy trying to find one :-) so thanks!. When I search I find your thirst for knowledge weaved throughout the web. I suppose my next step is to upgrade Alsa to 1.0.19 to reproduce this behaviour. After researching and searching your workaround seems to make sense and I also am confused as to why Mscore would be configured this way. The max-user-freq settings to hpet seems to be a key (clue & cue) but finding the lock it fits could be the first step and the first step is always the most important one. $ grep HPET /boot/config-2.6.29-1-multimedia-686 CONFIG_HPET_TIMER=y CONFIG_HPET_EMULATE_RTC=y CONFIG_HPET=y CONFIG_HPET_MMAP=y Going to look at ALSA 1.0.19 now, looking forward to reading your next post. Edit: Just reading mail that quotes the reason libsndfile jumped from 1.0.17 through to 1.0.19 quickly was because 1.0.18 had a serious security bug and should be avoided. Cheers! Dave.

Dave, I have a question at this point. I have ALSA 1.0.19 installed, and all works fine. This version of Alsa uses the HPET timer, as opposed to RTC, and i can see this in my proc/dev directory. In my /dev directory i have rtc0, and i've had to make a symlink, and call it "rtc", so that Mscore, and i assume Muse, have a timing device to recognise. It works, after a fashion, although i have to run mscore as root. (All attempts to adjust permissions chmod and chgrp have failed, in my attempt to have user permission access to /dev/rtc) I understand here that this is a workaround, as a result of Mscore's insistence on using only the rtc timer. (I will admit, i still don't understand the reasons for this.) So how do we make the link to hpet, so that Mscore 'sees', and uses, what it thinks is rtc, when in reality, it's using the new hpet setup. Is this even possible? And can we apply the same max-user-freq settings to hpet, as has been the traditional tweak for rtc? Alex. Update: After finally getting some sleep, and turning the overworked PC off, all settings for using Mscore with LS, through multiports out, are lost, and/or mixed up. Flutes are now using tympani channel, 1st violins are now using oboes. Without a reliable, user defined, port channel setup, it seems soundfonts, whether using the internal engine, or external soundfont player like qsynth , are the only option for any degree of reliability, at this stage in Mscore development. And i've just had a reply from Werner, informing me he's planning a rewrite, dumping alsamidi, and the reliance on the rtc timer, for jackmidi. There's some other details as well, but it seems while he generously provided a means of externally porting midi, it is still reliant on patch designation, so my straight channel to channel, with defined instrument in LS was unlikely to work anyway. More to come..................

Hi Alex, No problem I'm learning loads here and this install will be gone soon. I still haven't had a chance to check everything out yet but Ardour, Rosegarden and my main apps seem fine. Once I get reinstalled I will start over, but this time I have a better idea of the targets thanks to your posts. Free is a brilliant developer and if it's possible to provide us with the latest software he does, if not you can guarantee there's a good reason. 64studio is changing and developing at a tremendous rate but you can still feel the stability that's always been present. It's a very exciting time and the community & testers are all doing a great job. Edit: Cleaned up svn compile and build\install MuseScore 0.9.4. The compile and build was much smoother this time. Cheers! Dave.

Hi Alex, Because this install is purely for testing I've tested your QT4 packages & Musescore 0.7 build. I wouldn't push this far with my default studio but wanted to see what if anything broke. $ sudo apt-get build-dep mscore The following NEW packages will be installed cmake context doxygen dpatch gcj-4.2-base graphviz ladcca-dev libfluidsynth-dev libgcj-common libgcj8-1 libruby1.8 lmodern pdftk portaudio19-dev ruby ruby1.8 texlive-metapost uuid-dev debian testing sources: $ sudo apt-get install cmake libqt4-core libqt4-dev libqt4-gui libqt4-qt3support libqt4-sql qt4-dev-tools $ dpkg -l |grep qt4 ii libqt4-dev 4.4.3-2 + others $ dpkg -l |grep cmake ii cmake 2.6.2-4 ii cmake-data 2.6.2-4 $ svn co https://mscore.svn.sourceforge.net/svnroot/mscore mscore All built ok, I need to spend some time to see if anything has broken. Cheers! Dave

Hi Alex, Great posts, thanks. :-) I've got as far as libsndfile and jconv installed but got a bit distracted finishing my kernel tests, so sorry about the delay in posting. I need to reinstall and go through this first part all over again so as to get comfortable with the process. Libsndfile was the part that I found the most confusing, libsndfile 1.0.19. was the version I went for and it seems to be working ok. I need a step by step compile\install up to jconv to get used to installing the dependencies, it would be great to have installable packages built to make installing easier, and I'm only going to achieve this by taking one step at a time. Gnome allowing the user to define which desktop an app opens into by default is an interesting concept and would certainly be a great aid in workflow. I didn't know kde could do this but I'm going to look into it. Thanks again for all your help. Edit: Before reinstalling I have continued with the howto and compiled and installed down to the java based Fantasia. All seems well but drobilla-lad needed quite a few dependencies installed from debian testing? then the build was clean without any errors, but I'm not sure about pulling from debian testing and mixing sources this way. I also compiled and installed JSampler as a test. Now I just need to learn how to get it all up and running ;-) Cheers! Dave

I've had a long term challenge with Traverso, that with later builds of Jack, tends to segfault, and crash. I've also asked Ramon if he could take a look at it, testing with the latest jack version. Can anyone else confirm or deny this? Traverso is quite handy for building 'human' string runs, and unique phrases, etc.. and i'd like to keep using it if possible. Currently, i can only get it running, after a fashion, in my debian 32bit build, but still no success with 64Studio Beta 3. This may well be some sort of user error on my part, so experiences and input from others would be welcome. Alex.

Dave, as you know my setup is fairly simple. Orchestral music, and a desire for good workflow. The source packages i usually go to by default are: Jconv. Fons has just released an update, as i wrote previously. Drobilla-lad This set of apps contains two i use, being patchage and Ingen. I have a good time with patchage, it's easy to use and i can see at a glance, what's connected where. My setup is fairly static, once it's, erm, setup, but keystroking quickly through workspaces, to see your entire patched setup, at a glance, certainly makes a lot of sense, and minimises the time spent trying to sort something out that may not be working quite right. I've been working with Ingen to get my head around the multilayer paradigm, with a view to setting up more complex templates for writing and recording. I can see a potentially big opportunity in Ingen, as a host for all sorts of plugins, devices, unique patching arrangements, a greater degree of Midi and OSC control, etc... I'm already finding it useful, and for those who experiment with more than just a sampler, or single playback device, Ingen is quite powerful. Building a patch layer for one big sampler (example), with the routing going to the 'master' page, and having the ability to have several of those layers, routed to Master, and/or each other seems to be a much more user definable environment. Aeolus. The version in the repos is ok, but i'm having a good run with the latest release, 0.8.2. Ambdec I had a conversation with Fons and Jorn via email about Amibisonics, and with a lot of patience on their part, i started getting my head around it. Still a long way to go, but the intent of understanding this was related to a conversation Fons and I had some time ago, about a complete convolution soundscape, an idea i've been thinking about for a long time. We do so much work adding convolution by instrument, or audio track/output, seeking to emulate a stage or hall output, but it's coarse, in the sense it's often 'group' based and not so refined when dealing with instruments, sections, tonal differences, quality of samples used, etc. The intent was to reverse the process visually, and have a complete soundscape (i.e. GUI map of a stage) INTO which we put instrument icons, or some sort of visual device, placing them in appropriate positions. So you'd have a complete map of a stage, with lots of icons representing orchestral instrument placement. (And the ability to move them around at will, hearing the 'new placement' as you go.) In order that i gave better info and possibly asked better questions, i needed to understand a lot more about multi speaker setups, surroundsound, and more of the complexities of creating and using a complete space into which we 'record.' So Ambdec is another source package that is not only serving a purpose as a tool of use, but for educational reasons too. Jconv, Aeolus, and Ambdec can be D/L from here: http://www.kokkinizita.net/linuxaudio/downloads/index.html and Dave Drobilla's LAD packages can be D/L here: svn co http://svn.drobilla.net/lad/trunk drobilla-lad To build jconv, be sure to add the updated zita-convolver first, and the usual libs. (And Fons has very generously built some new impulse and ambdec examples, all neatly archived for D/L, so they would be worth trying too.) drobilla-lad can only be built from svn, and you'll need to access Debian testing to obtain a late build of raptor. Once the dependencies are satisified, LAD built without a single error here, so i hope you have the same success, should you try this. Linuxsampler is also a source install, and the frontend is the Java based Fantasia. I've put Qsampler to one side for now, as it has only single bank capability, and i've got way more than that to contend with. **A quick update for Musescore users.** I finally manage to get multimidi port out working, with a provisio. Using Linuxsampler as the sounddevice, the staff order in Mscore must EXACTLY match the channels in LSampler, IN ORDER. So piccolo=port0/mcha1, flute=port0/mcha2, etc.. When the first port and 16 channels are used (16 staves), then mscore automatically jumps to port1/mcha1 and goes on from there in strict sequence. (ports are numbered from 0) Maybe this might help someone struggling with the same setup. I used a 25 stave score, 2 midiout ports in Mscore, and 25 channels in LS. I've posted a question in the Mscore forums, asking if the user can allocate a defined port/channel, but no answer so far. ( either yes i can and i missed it in the manual, or not, that's not built yet.) I ran my larger template last night, doing some writing in RG, and 64 beta 3 hummed along nicely, with no glitches, xruns, or anything else. I'm going to open the 90 track/40buss Ardour template today, add a big Jconv IR, and the 'large' LS template, and see if it still fires nicely while the PC is glowing red with effort. :) Alex. p.s. A long term wish is for Gnome to evolve into allowing the user to define which desktop an app opens into by default. I've had a tinker with devilspie, but mixed success so far. If this happens at some time in the near future, then in terms of workflow, my system will be near enough automated, from boot on, to ready to write. I know i can do this in kde, but it's not really my cup of tea. So if anyone at 64studiocentral has any sway with the gnome devs, it might be worth a mention .:)

Throughout the process of creating 64studio 3.0 alpha\beta I have used a benchmark project in Ardour to compare Audio performance between 64studio 2.1\lenny dist-upgrade and 3.0 hardy alpha\beta. The 3.0 alpha\beta was always showing the worst performance with the Ardour benchmark project playing looped, it was only a small discrepancy 1% - 2% worse than 2.1\lenny but no amount of tweaks and configuration changes could get the performance to balance until I removed Timidity. Today with Timidity removed I now have 3.0 alpha\beta performance on an equal par and performing the best to date. - - - - - - - - - - - - - - - Daniel wrote: Unfortunately the Ubuntu packages (Timidity, solfege, stopmotion, fam) are where the bugs are, so the better option would be to provide a fixed backport in the repository. Quentin wrote: - - - - - - - - - - - - - - - I'm really enjoying reading your journey so far Alex and it would be great if you would write some howto's and methods\links. I have a fresh install here and would like to try some of the source installs you are using. Cheers! Dave

I also removed my Timidity after I tried to decrease the latency and ended up always burning 15% of one of my processors running Timidity in the background - with no advantages I could see.

A quick follow up. /dev/shm kept coming up as a failure at boot verbose, so i switch to the other option of tmp. All is now well with Jack, and the only notification i get is kernel source not installed, which i gather you chaps know about. Dave, thanks for the feedback about Timidity. It confirms there's something going on there that isn't so healthy, or needs a further degree of configuration. Either way, it's gone here, and things are good. The 64Studio OS itself is faster than anything i've used so far. Just simple things like opening and closing windows, running terminal apps, etc, feel......snappier. Hard to quantify, but definitely more sprightly, imho. I reported before about CPU use. I now have linuxsampler (medium orchestra template) jconv with orchestral IR, Ardour 2.7.1 (which is the fastest i've seen it operate), and rosegarden running, all smoothly, and quite a degree more efficiently than i'd previously experienced. No big crashes or stalls at all, so far, so nothing that i could say that needs fixing, or is broken, at this stage.. The testing journey continues......... Alex.

Hi Alex, I need to spend more time reading your last post, but I can confirm your Timidity test. After removal here my qjackctl & sound performance is much better. Thanks for the info, I'm looking forward to reading more of your journey into beta3. Cheers! Dave.

Thanks Dave. You kept talking about 64 studio so i figured it was time to see what the fuss was about. :) I've source installed my usual required apps, being: Jconv (new release0.8.0 with it's updated dependency, Zita-convolver-1.0.0) No problems with this at all. Linuxsampler Again, a bleeding edge install from CVS, incorporating libgig, lslscp, linuxsampler, and gigedit. I don't use qsampler much these days, but that got updated too. I also installed my weapon of frontend choice for linuxsampler, being Fantasia. No problems, and the following observations: With a medium orchestral template loaded, up to 80% of ram, it runs well. No glitches, spikes in CPU, or hesitations in playback, or midi response. I hammered it for over 2 hours, and it just kept humming nicely, which to me speaks volumes for the stability of the RT kernel, and associated midi. A proviso here. I uninstalled Timidity, which is usual for me, and frankly, i don't use it. After i did this and rebooted, i noticed i wasn't getting that first 'app start' xrun anymore. Whether this is relavent i'm not sure, but maybe more gifted heads than mine might want to have a bit of look at this. I wonder here if some of the perceived problems with xruns that some users have, could be as simple as taking Timidity out for the moment, and seeing what happens. I'd be interested in other users opinions on this, and what their own tests might reveal. Onto the next source install, which is Drobilla-lad.(Dave Drobilla's excellent packages, including patchage, ingen, etc..) This went well, except for a non 64studio repo dependency requirement for raptor. I found it in Debian Sid, and it installed without blowing anything up. Maybe the 64 Devs might consider adding this to their own repo, as an update. After raptor was done, drobilla-lad installed without an error, and opened and worked just fine. Dave, thanks for the boot verbose tip, it works, and that error has dissappeared. One more to deal with, and that's the line i inserted in Fstab, for jack (Dev/shm) This comes up as a 'device not found' error in boot verbose, so i'm going to try the Jack Fstab /tmp alternative and see what happens. It's the only error in boot remaining, so i'm keen to solve it for a clean boot. All is good otherwise. With LS using 3GB of ram for pre-loaded samples, and me going berserk switching midi channels, and robust polyphony, CPU is averaging 10-12%, which is a lot better than i had previously. (I think this is a combination of a more efficient kernel, Efficient OS, and great coding on the part of Christian and the team at LS) That'll change when i add the other apps, etc, but it's a great start. More to come... Alex. p.s. All this is happening in 64bit. 32bit is just so........last century. :)

Hi Alex, Nice report, great to see you up and running with beta3. Correct the kernel error message you see in the boot verbose. sudo gedit /etc/sysctl.conf Comment out this entry. kernel.maps_protect =1 The midi keyboards error is very strange, but you seem to have found a fix. Your testing is giving plenty of information for future development, and food for thought for other users. On the mailing list there was a post by Daniel suggesting there could be another change to the kernel to have firewire support out of the box. The present kernel is working very well here and I'm pleased to see others are having good results also. With 4gig of ram it might be worth researching vm.swappiness to make full use of the ram you have. Cheers! Dave.