64studio 3.0 observations

  • alex stone
Posted: Fri, 03/13/2009 - 03:38
Up and running with a fresh beta 3 (12/3, and the 2.6.29 RT kernel), and i add the following observations so far: During boot up i get a failure "kernel.maps_protect". No idea what this is, but everything kept going.... Once boot is finished, and the os is running, all seems fine so far. (And a good, quick, install with no problems.) I have two midi keyboards, that i don't turn on until the system is running, and qjackctl is open. When i then turn the keyboard on, and they appear in the Qjackctl window, i then get a nasty squawk, and the system locks hard, requiring a hardware reboot. Note: This happened on my regular Hardy UBstudio install at first. I upgraded Alsa from 1.0.16, to a source install 1.0.19, and the problem went away. I could then start and stop eitther or both keyboards, without a problem, or any type of crash. Maybe there's a clue here for the devs. (And it's the only crash or problem i've had.) I used Envy to install the opensource NV driver for graphics, and it all just works. (26" monitor.) And interestingly, i've just installed jack-1.9.1 (jack2) and no problem there either, with the current 1.0.17. So maybe between Alsa and Jack and the kernel, there's a version conflict of some sort. (I can't up update Alsa to 1.0.19 at the moment, because of some sort of missing kernel header or source, but you probably already know that.) I'm doing all this on an AMD64 X2 5600+, with 4 gig of ram, and no fear. I've also upgraded from source, libsndfile, to version 1.0.19. I appreciate this is probably quite brave/foolish/pickone, but there are a couple of apps that require at least 1.0.18, so maybe the devs might like to consider this as well, at least to version 1.0.18. Generally, so far so good, and i'm impressed with how quickly it boots up, and fast in general the OS performs. I've done the usual tweaks for Jack, etc, and with the 1.9.1 Jack2 version, it's running sweetly, and without xruns, at 128/44100/3. That's it so far. I'll install the latest CVS for linuxsampler, etc, and see what happens next. With the above observations taken into account, the sound works, the graphics work, almost directly "out of the box", so nice work fellas. Alex.

First Segfault

  • alex stone
  • 11/30/07
  • Sat, 03/21/2009 - 07:02
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.

realtime parchment studios build?

  • skullnotions
  • 09/29/07
  • Fri, 03/20/2009 - 11:54
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.

trial and error

  • alex stone
  • 11/30/07
  • Fri, 03/20/2009 - 10:41
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!

linuxsampler cvs

  • skullnotions
  • 09/29/07
  • Fri, 03/20/2009 - 09:47
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.

alsa

  • alex stone
  • 11/30/07
  • Thu, 03/19/2009 - 18:45
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.

2.6.29 - ALSA 1.0.19 - Mscore and Muse

  • skullnotions
  • 09/29/07
  • Thu, 03/19/2009 - 18:09
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.

only issue

  • alex stone
  • 11/30/07
  • Thu, 03/19/2009 - 18:46
Dave, Correct. Only the RTC kernel issue, which Werner has already indicated he's planning to change. (Woohoo) The rest is good. RG, Ardour, Jconv, Linuxsampler, etc, all perform correctly, and without problems. Summary for my 64studio 64bit boot: Kernel= Free's 64studio 64bit 2.6.29-multimedia Alsa = 1.0.19 (and for extra flavour, i'm using a basic asoundrc that points all things alsa through Jack. I have jack as an autostart up app. So it's on from bootup.) HPET max-user-freq timer setting in /etc/sysctl.conf set to 3072. Jack2 (a.k.a. Jackmp) 1.9.1. Tweaks include the usual stuff with RT priority set to 89. I'm using a Delta44 soundcard. Runs at 128/44100/2 now without problems. Stable, and the only xrun i seem to get is when i open and close an app, and even then, only occasionally. QT4 = 4.4.3. No problems here either, but i'm not quite brave enough to try 4.5, just yet. Ardour. Standard version available in 64studio beta 3. No problems. RG. Same, and it runs really well. Jconv = 0.8.0. Fon's latest version, and no problems at all. (Zita-convolver needs updating too, to V1.0.0) Linuxsampler cvs install, latest version. No problems. (0.5.1.11cvs) The rest is reliable, stable, and runs without stalling, glitching, or hesitating. My Beta 3 report so far. I'm not sure i'll even upgrade. This one's a good'un.it So the Os is fine, no problems, no outstanding issues, and bootup shows no errors. I'm hammering it now with a big LS template, Jconv with a large IR, RG, and Ardour with 60tracks, and 40 busses, trying to break something. All good so far. Alex.

and still more

  • alex stone
  • 11/30/07
  • Thu, 03/19/2009 - 14:57
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.

hpet.

  • alex stone
  • 11/30/07
  • Thu, 03/19/2009 - 14:22
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.

Re:2.6.29 & ALSA 1.0.19

  • skullnotions
  • 09/29/07
  • Thu, 03/19/2009 - 13:19
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.

aaah, damn

  • alex stone
  • 11/30/07
  • Thu, 03/19/2009 - 13:09
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.

2.6.29 & ALSA 1.0.19

  • skullnotions
  • 09/29/07
  • Thu, 03/19/2009 - 12:00
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

HPET timer, as opposed to RTC

  • skullnotions
  • 09/29/07
  • Thu, 03/19/2009 - 07:39
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.

hpet

  • alex stone
  • 11/30/07
  • Thu, 03/19/2009 - 12:55
Dave, Thanks for the info. I read the same mail! :) I'm also trying to find info regarding hpet and max-user-freq, but nothing yet. It would seem to make sense that hpet can be adjusted in the same way as rtc, but i'm no coder, so i don't know if it can be modded with the same command. The rtc workaround works, and i don't seem to have any aftereffect for doing it, so that's a step forward. But i would be interested to know if the rtc0 i see in /dev is actually rtc, or a default hpet emulation. I can't yet find info about this either, but i'll keep looking. Alsa 1.0.19 works fine here, and we seem to have crossed that uncertain patch that was alsa 1.0.18 (that needed a patch), jack 0.109, and 2.6.27-28 kernels and their challenges, relatively unscathed. Current successful setup: 64studio's 2.6.29 RT kernel, Alsa 1.0.19, Jack2 (formerly jackmp) 1.9.1. More to come, in a rathe enjoyable journey. I continue to be impressed with the beta 3 build, and just how robust it is. :) Alex. p.s. I'm rather pleased Werner's 'seen the light' and is going to reconfigure for jackmidi. I should imagine users who have struggled with the rtc drama over some period of time will breathe a collective sigh of relief. :) you mentioned you're assembling an article on notation apps. I respectfully suggest you consider including some enthusiasm for the Denemo team. They're coding like maniacs at the moment, and the app's really taking shape. Currently, Jeremiah and Richard are extremely active building a jackmidi framework into the app, with the option of a port per staff. I've been testing this, and it works, within the current code set. More to do, but they've been firing on all cylinders. Some fine work to be admired and encouraged. :)

Alsa

  • alex stone
  • 11/30/07
  • Wed, 03/18/2009 - 17:43
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..................

No Problem :-)

  • skullnotions
  • 09/29/07
  • Wed, 03/18/2009 - 05:08
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.

QT4 & mscore-0.7

  • skullnotions
  • 09/29/07
  • Tue, 03/17/2009 - 16:08
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

apologies

  • alex stone
  • 11/30/07
  • Tue, 03/17/2009 - 16:45
Sorry Dave, A lack of clarification on my part reference QT. The svn build of musescore is asking for QT4.5, which i understand came out a couple of weeks ago. It doesn't neglect 4.4.3, which i have installed without a problem, but the user has to manually adjust flags in the CMakelist.txt file. (Commenting out a couple and changing 2 others from True to False.) Mscore 0.7. works well enough here, but naturally lacks many of the recent features. That's a choice on my part, not a criticism, or a challenge with the version supplied with 64Studio. (Hence the apology. The version supplied with the OS does work.) The more important issue coming up will be RTC timing, strictly required by mscore, and muse as the only timing option, and the advent in up to date Alsa of Hpet timing. Again, a conversation some time ago with Paul, and Fons, had us all asking the same question. Why does Mscore insist on exclusivity with RTC timing? Rg handles this well in contrast, with more timing options than a swiss clock factory.. So, yes, Mscore 0.7. installs, and is usuable. 0.9.4 will install, with the added dependencies, and me manually adding symlinks, to try and get the rtc stuff sorted out. (I have no RTC on my system. It's RTC0, and i have to create an rtc file, then symlink to the rtc0 file, naming the link "rtc", before it all starts to work.) The svn mscore build "0.9.5" fails with the lack of QT4.5, or builds with warnings, when i comment out the QT4.5 build requirement, then runs in a fragile state, like using a glass hammer to belt a nail. And again, that wretched rtc message............. Sorry for the vague description. Regards, Alex.

libsndfile jconv Fantasia... Re: A simple setup

  • skullnotions
  • 09/29/07
  • Tue, 03/17/2009 - 11:49
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

the journey continues....

  • alex stone
  • 11/30/07
  • Tue, 03/17/2009 - 14:38
Dave, sounds good. I'd be interested in hearing what you think of Ingen, and the possibilites it provides. I'm still experimenting with it, but i reckon this might be a powerful tool in many an arsenal. As a testing contribution, and observation, it's my view that the 64studio team could have a look at 'reaching ahead' with some of the utilties, and added lib dependencies. libsndfile is a good example. It installed and works, with seemingly no aftereffects, or OS extinction level event. And for 64Studio 3.0, and the giant leap it's taken in kernel and app versions, maybe now is the time to finesse it a little further, and add the safe, state of the art libs, with a view to a reliable, modern libbase reaching well into the future. I find all the testing interesting, and a lot of enjoyment comes with the challenge of doing that, but the working build needs to be stable, and run day in, day out, without an issue. So far, with the added libs and dependencies, including those for drobilla-lad, i've had no problems. But i've reached the stage now, where i'm hesistant to step further, in case it's a step too far, and things start going wrong. (And let's not forget here, i'm the Gandalf of user error.) QT4 is a good case in point. Is this safe to update, and will it break 64studio 3.0.? I'm not sure, so it doesn't get updated, but already we have musescore 'asking' for this version in svn builds. And naturally, what will be the cost of trying this. Will it break other apps, or create a degree of instability? I've backed off in my entire time with linux, away from the bleeding edge, when it comes to the 'parchment studio' working build. All those apps have been stable, if old. (The testing stuff has been unhindered by hesitation, and as you know, i'm not afraid to push the limit...:) ) 64studio is now the parchment studio build, and it works, every day. I needed to know it was ok through testing, but once installed and running, it just works, without a hassle. (and better than my previous much tweaked and loved build of UBStudio Hardy.) Packages for Jconv would be good. With the three essential libs (clxclient, clthreads, and clalsadrv, or something like that) as dependencies in 64studio by default, i don't think we'd lose anything, and gain much. Add to that the current Jconv-0.8.0, and Zita-convolver-1.0.0, and we'd have a '64Studio' convolution app by default, for users. In terms of an overall studio build, and in the presentation of a complete audio/midi/recording workstation, i would think the updated Jconv as a default inclusion would be a very powerful icing on the cake. I respectfully ask the 64studio devs to consider this. The latest build is stable here with the beta 3 build, and i've had no problems at all using it. Quite the contrary. Jconv, with the 2.6.29 RT kernel runs efficiently, and with the new features Fons has added, would definitely be a welcome asset. (imho) For those much cleverer than i in these matters, maybe a packaged Jconv build, including examples, added wavs, etc, would be the ticket. And this might just prove an added incentive for Fons to consider a jconv GUI. :) KDE indeed gives you the ability to open apps into defined workspaces. I had this conversation with Paul Davis a little while back, and he patiently explained why KDE does this, and why Gnome doesn't. I've already expressed my enthusiasm for a solution to this in Gnome/Metacity, so i won't make myself unwelcome, and labour the point. :) With the current build, and my few added extras, i've reached the point of no further. I'm not going to push the edge, and although there's a couple of casualties with any decision in the same ilk, the stability is essential, and i have this. Timidity, and latebuild Musescore are out in the 64Studio build, Source built Jconv, Linuxsampler, and drobilla-lad are in. It all works very well indeed. Regards, Alex.

Traverso

  • alex stone
  • 11/30/07
  • Sun, 03/15/2009 - 12:07
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.

A simple setup

  • alex stone
  • 11/30/07
  • Sun, 03/15/2009 - 11:42
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 .:)

qjackctl% & Audio Performance.

  • skullnotions
  • 09/29/07
  • Sun, 03/15/2009 - 09:12
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

Timid

  • Quentin Harley
  • 05/24/07
  • Fri, 03/13/2009 - 19:09
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.

shm versus tmp

  • alex stone
  • 11/30/07
  • Fri, 03/13/2009 - 18:58
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.

uninstall Timidity

  • skullnotions
  • 09/29/07
  • Fri, 03/13/2009 - 17:03
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.

continuing the journey....

  • alex stone
  • 11/30/07
  • Fri, 03/13/2009 - 16:01
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. :)

Re: 64studio 3.0 observations

  • skullnotions
  • 09/29/07
  • Fri, 03/13/2009 - 11:17
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.